Глава 6. Администрирование информационной базы

При работе с системой «1С:Предприятие» необходимо выполнять различные действия, связанные с администрированием системы, например:

● ведение списка пользователей;

● назначение прав пользователям;

● резервное копирование;

● создание технологического журнала для разбора ошибок и т. д.

Конфигуратор содержит средства администрирования, предназначенные для решения указанных задач.

Так, в системе «1С:Предприятие» существует возможность создания списка пользователей, которым разрешена работа с системой. Этот список будет использоваться для авторизации пользователя при его входе в систему. Следует обратить внимание, что список пользователей системы «1С:Предприятие» не является частью конфигурации: он создается отдельно в конкретной организации, в которой используется система.

Для каждого пользователя может быть установлен пароль на вход в систему. Пароль используется для подтверждения прав пользователей на работу в системе «1С:Предприятие».

Другой важной задачей административного характера является ведение резервного копирования. Проведение этой процедуры должно выполняться периодически, чтобы в случае разрушения базы данных иметь возможность с минимальными потерями восстановить исходные данные. Частота определяется интенсивностью изменений данных. Чем чаще меняются данные, тем чаще следует производить резервное копирование.

В этой главе будут рассмотрены вопросы администрирования «1С:Предприятия», которые можно выполнять с помощью конфигуратора.

Список пользователей вызывается на экран выбором пункта Администрирование ‑ Пользователи.

Рис. 56. Список пользователей

Окно со списком пользователей имеет панель инструментов и табличное поле с двумя колонками:

● В колонке Имя выводится список пользователей, зарегистрированных для работы с системой «1С:Предприятие 8».

● Колонка Полное имя может содержать расшифровку имени, выданного в первой колонке.

Пользователи, для которых определен пароль доступа, отображаются пиктограммами с замочком (пользователь Продавец на рис. 56).

Пользователи, для которых не определена роль или аутентификация, отображаются пиктограммами с вопросом (пользователь Менеджер по продажам на рис. 56).

С помощью пунктов меню Действия осуществляется ведение списка пользователей, настойка показа списка (отбор, состав и порядок колонок, сортировка), а также вывод списка в табличный или текстовый документы.

Изменение свойство пользователей информационной базы возможно с помощью встроенного языка. Для этого следует использовать свойство глобального контекста ПользователиИнформационнойБазы и объект типа ПользовательИнформационнойБазы.

Для добавления нового пользователя необходимо выбрать пункт Действия ‑ Добавить в окне Список пользователей. На экран будет выдано окно для редактирования параметров пользователя.

На закладке Основные указывается имя и полное имя пользователя.

Рис. 57. Новый пользователь

В имени пользователя не рекомендуется указывать символ ":". Уникальность пользователя информационной базы поддерживается по совокупности значений трех полей: имя, полное имя и имя пользователя операционной системы (если включена аутентификация средствами операционной системы). Для поля Имя уникальность поддерживается по первым 64 символам, для поля Полное имя ‑ по первым 128 символам, для поля Пользователь (при включенной аутентификации операционной системы) ‑ по первым 128 символам. Рекомендуется не допускать для поля Имя превышения длины в 64 символа.

Указание значения в поле Адрес электронной почты позволит пользователю выполнять аутентификацию с помощью электронной почты (описано далее). Кроме этого, поля Адрес электронной почты и Пользователю запрещено восстанавливать пароль относятся к механизму восстановления пароля пользователя. Если не указано значение поля Адрес электронной почты, то этот пользователь не сможет восстановить пароль по электронной почте, только через веб-сайт. Каждый пользователь информационной базы должен иметь уникальный адрес электронной почты (уникальность проверяется без учета регистра символов). Адрес электронной почты не может превышать 128 символов в длину. Если у пользователя установлен флажок Пользователю запрещено восстанавливать пароль, то забытый пароль можно будет восстановить только с помощью администратора системы. Подробнее про восстановление пароля см. здесь.

Для пользователя необходимо указать способ аутентификации. Подробнее про виды аутентификации, которые поддерживает «1С:Предприятие», см. здесь.

Каждый из флажков Аутентификация… (Аутентификация 1С:Предприятия, Аутентификация операционной системы, Аутентификация OpenID, Аутентификация OpenID Connect, Аутентификация токеном доступа, Аутентификация QR кодом, Аутентификация через электронную почту) определяет возможность выполнения аутентификации для данного пользователя тем или иным способом (подробнее о видах аутентификации см. здесь). Эти флажки не влияют на порядок попыток аутентификации. При назначении видов аутентификации следует помнить о следующих особенностях:

● Если сняты все флажки Аутентификация…, то данному пользователю запрещен доступ к прикладному решению.

● Для того чтобы выполнялась попытка аутентификации с помощью протокола OpenID, OpenID Connect или с помощью QR-кода, необходимо, чтобы соответствующим образом была настроена публикация информационной базы на веб-сервере (см. здесь).

● Пользователю будет запрещен доступ к прикладному решению, если он аутентифицирован средствами ОС, OpenID, OpenID Connect или QR-кодом, но у вида аутентификации сброшен флажок, разрешающий эту аутентификацию для пользователя.

● Отключить попытку аутентификации средствами ОС или с помощью OpenID можно соответствующими параметрами командной строки запуска клиентского приложения.

Для того, чтобы выполнялась аутентификация операционной системы, необходимо включить флажок Аутентификация операционной системы, а затем выполнить сопоставление пользователя операционной системы и пользователя информационной базы. Для этого необходимо в поле Пользователь (становится доступным после установки флажка Аутентификация операционной системы) указать пользователя операционной системы. По значению поля Пользователь будет выполняться поиск соответствия текущего пользователя операционной системы и пользователя информационной базы. Пользователь операционной системы указывается в формате: \\имя_домена\имя_пользователя. Имя пользователя операционной системы не может превышать в длину 128 символов.

Для того, чтобы выполнялась аутентификация с помощью электронной почты, необходимо включить флажок Аутентификация по электронной почте и указать адрес электронной почты пользователя в поле Адрес электронной почты.

Если установлен флажок Пользователю запрещено изменять пароль, то это означает, что данный пользователь не может изменять свой пароль (используется, если включена аутентификация системы «1С:Предприятие»).

Если флажок Показывать в списке выбора установлен, то данный пользователь будет отображаться в списке выбора при соединении с информационной базой системы «1С:Предприятие». Если пользователю запрещена аутентификация средствами системы «1С:Предприятие», то флажок Показывать в списке выбора становится недоступным для редактирования, а пользователь не будет отображен в списке выбора при соединении с информационной базой.

Флажок Защита от опасных действий указывает, что для данного пользователя такая защита включена. Подробнее о защите от опасных действий см. здесь.

На закладке Прочие указываются доступные роли и язык. Если ролей в конфигурации определено несколько, то для пользователя можно также указать несколько ролей. Кроме того, для пользователя можно указать режим запуска «1С:Предприятия». Если используется значение Авто, то при запуске будет использоваться режим запуска, установленный в свойстве конфигурации Режим запуска. Указание конкретного режима запуска можно использовать в тех случаях, когда некоторые пользователи должны работать в особом режиме. Например, какой-либо пользователь работает в режиме управляемого приложения. Тогда в поле Режим запуска стоит указать Управляемое приложение.

Рис. 58. Прочие параметры нового пользователя

Свойство Ключ требования назначения предназначен для того, чтобы иметь возможность распределять подключения пользователей по рабочим серверам (подробнее см. здесь).

В окне для редактирования свойств пользователя не обязательно заполнять сразу все поля ‑ это можно сделать позднее.

Если в системе включено разделение пользователей (подробнее см. здесь), то среди параметров пользователя будет дополнительно отображаться закладка, связанная с разделением данных.

Рис. 59. Разделение данных

На закладке отображаются все доступные разделители (не все общие реквизиты), при этом можно для каждого разделителя указать значение разделителя и его использование при аутентификации пользователя. Установленный флажок слева от имени разделителя означает, что для текущего пользователя установлено значение выбранного разделителя. При этом само значение указывается в поле ввода справа от имени разделителя. Если для пользователя указано значение разделителя (причем не только значение, но и признак «использования»), то изменение значений свойств разделителя Разделение пользователей и Разделение аутентификации начинает оказывать влияние на видимость и доступность данного пользователя для выбора и аутентификации.

Нового пользователя можно создать путем копирования существующего. Используя такую возможность, нет необходимости создавать нового пользователя с нуля ‑ достаточно скопировать одного из уже существующих в списке пользователей и отредактировать его свойства.

Для копирования нужно выбрать исходную строку списка пользователей и выполнить команду Действия ‑ Скопировать.

При копировании имя пользователя может быть преобразовано с целью соблюдения уникальности. Остальные свойства нового пользователя будут такие же, как и у пользователя, выбранного в качестве образца (кроме пароля).

С целью предотвращения входа пользователей в систему «1С:Предприятие» под чужими именами каждому пользователю, которому разрешена работа с системой, может быть установлен пароль на вход. Как и имя пользователя, пароль служит для подтверждения полномочий пользователя на работу в системе.

Рис. 60. Установка пароля пользователя

В поле для ввода пароля нужно ввести пароль пользователя. Пароль должен удовлетворять политике паролей, установленной для информационной базы или пользователя (просмотр политики паролей, установленной для пользователя, доступен только из встроенного языка). Размер пароля не должен превышать 255 символов. При вводе пароль отображается звездочками, поэтому будьте внимательны.

Если пользователь не хочет придумывать пароль самостоятельно, то он может воспользоваться встроенным генератором паролей. Для этого необходимо нажать гиперссылку Сгенерировать пароль. Пароль, сформированный при нажатии на эту гиперссылку, также учитывает состояние параметров информационной базы. Параметры пароля, сформированного системой, зависят от минимальной длины пароля, указанного в параметрах информационной базы:

● Минимальная длина установлена менее 7 символов. В этом случае пароль будет состоять только из строчных букв латинского алфавита.

● Минимальная длина установлена в 7 символов и более. В этом случае пароль состоит из цифр, строчных и заглавных букв латинского алфавита. Пароль удовлетворяет критерию сложности пароля вне зависимости от установки соответствующего параметра информационной базы.

● Минимальная длина пароля не контролируется (установлена в значение 0). В этом случае пароль формируется исходя из следующих установок: длина пароля 7 символов, пароль должен быть сложным. Пароль будет состоять из цифр, строчных и заглавных букв латинского алфавита.

Доступность поля Подтверждение пароля зависит от того, каким образом формируется значение в поле Пароль:

● Пароль формируется пользователем самостоятельно. В этом случае поле Подтверждение пароля доступно для повторного указания задаваемого пароля. Если повторно введенный пароль отличается от первоначального, то при нажатии кнопки ОК на экран выводится предупреждение Пароль и подтверждение пароля не совпадают, и пароль не будет установлен.

● Пароль формируется с помощью встроенного генератора паролей. В этом случае поле Подтверждение пароля недоступно для использования, система автоматически подставит туда новый пароль. Если сформированный пароль чем-то не устраивает пользователя ‑ можно сформировать новый пароль повторным нажатием на гиперссылку Сгенерировать пароль (количество повторных нажатий не ограничено).

Если пароль пользователя изменен, а кнопка ОК еще не нажата, то имеется возможность посмотреть заданный пароль. Для этого существует кнопка в правой части полей Пароль и Подтверждение пароля. Циклическое нажатие данной кнопки меняет режим отображения пароля: пароль отображается реальными символами или маскирующими символами. После того, как пароль установлен и форма открыта заново ‑ посмотреть пароль уже нельзя. В поле ввода пароля показывается надпись Пароль установлен, но посмотреть пароль невозможно.

Для того, чтобы очистить установленный пароль ‑ следует нажать сочетание клавиш Shift + F4 в поле Пароль (или Подтверждение пароля). Пароль будет очищен сразу в обеих полях ввода (если пароль формировался системой) или в текущем поле ввода (если пароль создавался вручную пользователем).

Если вы передумали устанавливать пароль, то нужно нажать кнопку Отмена. Следует понимать, что если кроме смены пароля, в этом диалоге были выполнены еще какие-то изменения, то нажатие кнопки Отмена приведет не только к отмене смены пароля, но и к отмене всех остальных выполненных изменений.

Если пользователь забыл свой пароль, то восстановить его можно следующими способами:

● Задать пользователю новый пароль. Для этого требуется административный доступ к списку пользователей.

● Выполнить процедуру восстановление пароля. Для этого такая процедура должна быть настроена в информационной базе и пользователю должно быть разрешено выполнять это действие.

Пользователи, имеющие пароль, отличаются в списке пользователей пиктограммой (замочек на пиктограмме ‑ см. пользователь Продавец на рис. 56).

Смотри также:

● Параметры информационной базы (см. здесь).

В зависимости от информационной базы и уровня доступа пользователей, могут меняться требования к сложности, уникальности и «времени жизни» пароля. Каким-то пользователям будет достаточно простого пароля с длинной не менее определенного количества символов, каким-то пользователям требуются сложные пароли с определенным временем жизни и т. д.

Для реализации такой возможности, система «1С:Предприятие» предлагает механизм политик паролей. Политика паролей ‑ это набор требований, направленных на повышение безопасности информационной базы путем принуждения пользователей к использования паролей с определенными характеристиками и правильному использования этих паролей.

Политика паролей может задаваться как для информационной базы в целом, так и для конкретных пользователей. В том случае, если политика паролей настраивается для информационной базы в целом, используется диалог редактирования параметров информационной базы. В этом диалоге используется группа Требования к паролям, которая содержит некоторый набор параметров. Забегая вперед, отметим, что ровно этот же набор параметров будет использоваться и для доступа с помощью встроенного языка. В этом случае используется объект ПолитикаПаролейПользователей.

Политику паролей пользователей описывает некоторый набор параметров. Эти параметры могут изменяться как интерактивно, так и через объект ПолитикаПаролейПользователей из встроенного языка. Поэтому для каждого параметра (в скобках) приводится имя свойства этого объекта.

Если данный параметр установлен, пароли пользователей должны удовлетворять следующим требованиям:

● Минимальная длина пароля должна быть больше или равна максимальному значению из числа 7 и значения свойства Минимальная длина паролей пользователей.

● Пароль должен состоять из символов, относящихся как минимум к трем из перечисленных групп:

● заглавные буквы;

● строчные буквы;

● цифры;

● специальные символы.

● Пароль не должен совпадать с именем пользователя.

● Пароль не должен являться последовательностью символов.

Использование ограничений на пароли пользователей информационной базы не влияет на существующие пароли. Ограничения будут применены только при изменении существующего пароля или при добавлении нового пользователя информационной базы. Однако проверка пароля выполняется по текущей настройке информационной базы. В частности, это означает, что при включении параметра Проверка сложности паролей пользователей проверка пароля начнет выполняться с учетом регистра.

Например, если для пользователя (по каким-то причинам) был задан пароль PaRoL, то до включения параметра Проверка сложности паролей пользователей пользователь мог вводить пароль и так: parol, и так: PAROL, и так: ParoL, и всякий раз система разрешала ему доступ в систему. После установки параметра Проверка сложности паролей пользователей вход в систему будет разрешен только в том случае, если пароль будет введен с учетом регистра: PaRoL.

Данный параметр указывает, что в данной информационной базе пароли будут проверяться не только на сложность (если соответствующий параметр установлен), но и на возможность указания такого пароля в принципе. Основанием могут различные причины, например, пароль много раз был скомпрометирован или пароль не может быть указан по причине несоответствия корпоративному списку стоп-слов.

Настройка параметров проверки раскрытия паролей задается в диалоге Дополнительные настройки аутентификации (см. здесь) или с помощью встроенного языка (см. здесь).

Указывает минимальную длину пароля пользователя. Если установлен параметр Проверка сложности паролей пользователей, то минимальная длина пароля пользователя не может быть менее 7 символов. Однако, с помощью встроенного языка предоставляется возможность установить любую длину пароля, даже если в параметрах политики пароля установлено данное свойство.

Если пароль пользователя не соответствует текущей политике паролей (системной или пользователя), то администратору предоставляется выбор, какое действие в этом случае будет предпринято платформой. Допустим один из следующих вариантов (значение системного перечисления ДействиеПриНесоответствииПароляТребованиямПриАутентификации):

● Нет. Ничего не делать.

● ПредложитьСменуПароля. Пользователю сообщается, что пароль не соответствует текущей политике и предлагается сменить пароль (открывается форма). Выполняется запись в журнал регистрации. Можно продолжить работу без смены пароля.

● ПотребоватьСменуПароля. Пользователю сообщается, что пароль не соответствует текущей политике и предлагается сменить пароль (открывается форма). Выполняется запись в журнал регистрации. Отказаться от смены пароля невозможно. Если пользователю запрещено изменять пароль ‑ формируется исключение и пользователь не может аутентифицироваться в информационной базе.

Определяет срок, по окончании которого пароль будет подлежать обязательной замене. Под термином «срок» понимается интервал времени от момента установки текущего пароля. Указанный интервал времени устанавливается в секундах.

При установке параметру значения 0, параметр не действует.

Определяет срок, до наступления которого пользователь не сможет сменить пароль. Под термином «срок» понимается интервал времени от момента установки текущего пароля. Указанный интервал времени устанавливается в секундах.

При установке параметру значения 0, параметр не действует.

С помощью параметра указывается интервал времени до окончания действия текущего пароля, начиная с которого система начнет предупреждать пользователя о необходимости смены текущего пароля. Указанный интервал времени устанавливается в секундах.

При установке параметру значения 0, параметр не действует.

С помощью данного параметра можно указать, сколько последних паролей будет использовать система при проверке уникальности нового пароля. Если, например, в качестве значения данного параметра указано значение 5, то новый пароль не должен совпадать ни с одним из 5 последних паролей данного пользователя.

При установке параметру значения 0, параметр не действует.

Описание работы с политиками паролей из встроенного языка см. стр. см. здесь.

Система «1С:Предприятие» позволяет управлять некоторыми параметрами диалога аутентификации, настраивать параметры восстановления забытого пароля пользователя, проверку раскрытия пароля и некоторые другие параметры. Все эти настройки выполняются с помощью диалог Дополнительные настройки аутентификации (доступен через Главное меню ‑ Администрирование ‑ Дополнительные настройки аутентификации).

На закладке Аутентификация можно выполнить настроить работу собственно механизма аутентификации.

Рис. 61. Аутентификация

Установка флажка Отображать гиперссылку "Нужна помощь?" открывает возможность установить значение свойства Адрес ссылки. В это поле следует ввести URL, по которому будет выполнен переход при нажатии в диалоге аутентификации пиктограммы с вопросительным знаком. Перед переходом гиперссылка будет дополнена параметрами области данных, для которой открыт диалог аутентификации. Параметры области данных задаются аналогично параметру Z командной строки запуска клиентского приложения (см. здесь). Результирующий URL будет выглядеть следующим образом: URL?Z="значения разделителей".

Флажок Разрешить сохранение аутентификации включает в диалоге аутентификации флажок Запомнить. С помощью этого флажка пользователь может запомнить вводимые параметры аутентификации и не вводить имя пользователя и пароль в течение некоторого времени. Время сохранения параметров аутентификации задается с помощью параметра Время жизни сохраненной аутентификации (в секундах). Эти же параметры могут быть заданы с помощью файла публикации информационной базы default.vrd. Настройки, заданные в файле default.vrd, имеют приоритет над настройками в диалоге Дополнительные настройки аутентификации.

При сохранении аутентификации, пароль, с помощью которого пользователь выполнил аутентификацию в информационной базе, не сохраняется на компьютере (это не безопасно). Вместо пароля хранится специальный токен, который ограничен по времени жизни и который зависит от пароля ‑ при смене пароля токен становится недействительным.

Если есть опасность несанкционированного доступа в информационную базу с помощью скомпрометированного токена сохраненного доступа, то рекомендуется, во-первых, заменить пароль для всех пользователей, чьи токены сохраненного доступа скомпрометированы или подозреваются в компрометации, а во-вторых, можно запретить аутентификацию тем способом, которым пользовались скомпрометированные пользователи. Надо понимать, что второй способ приведет к тому, что доступ к информационной базе не смогу получить и пользователи с актуальными (не скомпрометированными данными доступа) паролями/токенами сохраненного доступа. Выбор варианта решения зависит от размера предполагаемой компрометации, уровня доступа скомпрометированных пользователей и прочих параметров информационной безопасности в организации.

Если необходимо «забыть» сохраненную аутентификацию для какого-то пользователя, то этому пользователю необходимо изменить пароль (в Конфигураторе или с помощью административных инструментов прикладного решения). На всех устройствах, где пользователь сохранял аутентификацию (с помощью флажка в диалоге аутентификации), потребуется выполнить аутентификацию с помощью нового пароля.

Не рекомендуется одновременно включать возможность сохранения аутентификации и завершение сеанса при бездействии (см. здесь), если завершение сеанса при бездействии включается для минимизации рисков несанкционированного доступа к данным. В этом случае принудительное завершение сеанса не защитит от несанкционированного доступа, т. к. данные с помощью сохраненной аутентификации злоумышленник все равно сможет получить доступ к данным информационной базы.

Включенный флажок Сохранять аутентификацию по умолчанию позволяет настроить диалог аутентификации пользователя таким образом, что вид аутентификации, которым успешно воспользуется пользователь, будет способом по умолчанию при следующей попытке аутентификации в прикладном решении.

Смотри также:

● Файл default.vrd (см. здесь).

На закладке Аутентификация через электронную почту выполняется включение/выключение и настройка механизма аутентификации через электронную почту.

Рис. 62. Аутентификация через электронную почту

Возможность использования аутентификации через электронную почту управляется флажком Использовать аутентификацию через электронную почту. Если механизм включен и настроен, то пользователь должен в диалоге выбора пользователя указать необходимость выполнить аутентификацию через электронную почту.

Рис. 63. Выбор аутентификации через электронную почту

Затем в форме станут доступны поля для ввода адреса электронной почты пользователя.

Рис. 64. Ввод электронной почты

Адрес электронной почты следует ввести в поле с подсказкой Адрес электронной почты. Если в системе есть пользователь с такой электронной почтой ‑ ему будет отправлено электронное письмо в кодом подтверждения.

Введя в следующем диалоге код подтверждения, пользователь аутентифицируется в информационной базе.

Код подтверждения, который высылается по электронной почте, управляется набором ряд параметров, которые настраиваются на закладке:

● Длина кода ‑ указывается длина кода подтверждения аутентификации пользователя.

● Максимальное количество неуспешных попыток ввода ‑ указывает, сколько раз пользователь может ошибиться при вводе кода подтверждения. После превышения количества попыток ‑ полученный код становится недействителен. Пользователю необходимо запросить новый код подтверждения аутентификации.

● Длительность блокировки запроса обновления кода подтверждения ‑ интервал времени, который должен разделять два идущих подряд запроса кода подтверждения аутентификации пользователя.

● Срок действия кода подтверждения ‑ определяет время действия высланного кода подтверждения аутентификации. По истечении срока действия будет необходимо запросить новый код подтверждения аутентификации.

● Алфавит кода подтверждения ‑ содержит набор символов, из которых формируется код подтверждения. Строка может быть или пустой, или содержать от 10 до 256 различных символов. Если задана пустая строка, то алфавит состоит из десятичных цифр от 0 до 9 (включительно).

● Использовать стандартный сервис отправки ‑ флажок позволяет отправлять письмо с кодом подтверждения через стандартный почтовый сервис фирмы «1С». В этом случае невозможно изменять отправителя, тему, формат и содержимое электронного письма. Письма всегда будут приходить с адреса 1С:Подтверждение входа <authentication@1c.com> с темой Код подтверждения входа.

Если этот флажок сброшен, то появляется возможность настроить параметры отправки письма с кодом подтверждения. Эти параметры указываются в группе параметров Параметры отправителя.

В данной группе задаются параметры почтового сервера, через который будет выполняться отправка письма с кодом подтверждения, а также задаются параметры самого письма.

Гиперссылка Заполнить из настроек восстановления пароля позволяет заполнить настройки почтового сервера теми же настройками, как и у почтового сервера, который используется для восстановления пароля пользователя.

Параметры отправления задаются с помощью следующих параметров:

● Адрес сервера SMTP ‑ позволяет указать адрес SMTP-сервера.

● Пользователь SMTP и Пароль SMTP ‑ содержат имя пользователя и пароль, которые необходимы для аутентификации на SMTP-сервере.

● Порт SMTP ‑ сетевой порт, который используется для протокола SMTP:

● 465 порт ‑ для защищенных соединений (используется по умолчанию).

● 25 порт ‑ для незащищенных соединений.

● Использовать SSL ‑ указывает необходимость использования SSL для соединения с SMTP-сервером.

Параметры письма задаются с помощью следующих свойств:

● Имя отправителя ‑ текст, который будет отображаться в электронном письме в качестве автора письма (поле From).

● Заголовок сообщения ‑ текст, который будет указан в заголовке письма (поле Subject).

● Гиперссылка Текст сообщения ‑ позволяет открыть редактор HTML-документа, который позволит написать текст письма. В письме можно использовать следующие псевдопеременные для указания изменяющихся частей письма:

● ApplicationPeresentation ‑ представление конфигурации, которая используется в текущей информационной базе.

● UserName ‑ имя пользователя.

● UserPresentation ‑ полное имя пользователя.

● VerificationCode ‑ код подтверждения аутентификации.

В тексте письма значения переменных должны предваряться символом «&», например: Добрый день, &UserPresentation!.

Настройки аутентификации через электронную почту также доступны с помощью встроенного языка. Для этого предназначено свойства глобального контекста ДополнительныеНастройкиАутентификации.

Смотри также:

● Настройки аутентификации через электронную почту с помощью встроенного языка (см. здесь).

На закладке Восстановление пароля расположены параметры, с помощью которых выполняется настройка работы механизма восстановления пароля пользователя.

Рис. 65. Восстановление пароля

Система «1С:Предприятие» предлагает несколько способов восстановления забытого пароля пользователя. Управляет этим механизмом несколько настроек. Часть настроек расположена в свойствах пользователя информационной базы, часть ‑ в специальном диалоге настроек:

● Настройки пользователя:

● Адрес электронной почты ‑ адрес электронной почты, на который будет отправлено письмо с кодом, который необходим для установки нового пароля.

● Пользователю запрещено восстанавливать пароль ‑ установка этого флажка сделает невозможным восстановления пароля по электронной почте. Восстановить пароль можно будет только с помощью администратора информационной базы.

Возможность восстановления пароля путем перехода по навигационной ссылке (например, на веб-сайт) зависит от реализации логики этой страницы.

● Настройки самого механизма восстановления пароля находятся на закладке Восстановление пароля диалога Дополнительные настройки аутентификации (в описании которого мы сейчас находимся).

Пароль можно восстановить или с помощью специальной веб-страницы, или с помощью кода восстановления, отправленного по электронной почте. Выбрать оба способа восстановления пароля одновременно невозможно.

Для OpenID-аутентификации изменение пароля выполняется на стороне провайдере аутентификации, т. к. именно в нем выполняется аутентификация. После изменения пароля выполняется переход на форму аутентификации в провайдере. Выбор варианта восстановления пароля в этом случае зависит от возможностей, которые предоставляет используемый OpenID-провайдер.

Флажок Переход по навигационной ссылке включает возможность восстановления пароля путем открытия в веб-браузере страницы, адрес которой указан в свойстве диалога настроек Адрес ссылки. Перед переходом гиперссылка будет дополнена параметрами области данных, для которой открыт диалог аутентификации. Параметры области данных задаются аналогично параметру Z командной строки запуска клиентского приложения (см. здесь). Результирующий URL будет выглядеть следующим образом: URL?Z="значения разделителей". Вся логика восстановления пароля должна быть реализована на странице, адрес которой указан в настройках.

Флажок Отправка кода на адрес электронной почты позволяет включить восстановление пароля путем отправки специального кода на адрес электронной почты пользователя. В этом случае пользователю открывается диалог следующего вида:

Рис. 66. Окно ввода адреса электронной почты

Если указанный в диалоге адрес электронной почты задан для какого-либо пользователя информационной базы, то по указанному адресу будет отправлено письмо с кодом подтверждения, а пользователю будет показан следующий диалог:

Рис. 67. Указание кода подтверждения и нового пароля

В данном диалоге указано, на какой адрес направлено письмо, а также предлагается указать код подтверждения, который находится в письме, а также указать новый пароль для пользователя, связанного с той электронной почтой, на которую пришло письмо с кодом. При указании нового пароля выполняется проверка пароля на соответствие политике паролей, которая установлена для пользователя (которому восстанавливается пароль) или для информационной базы (если для пользователя политика не указана или политики с таким именем нет в информационной базе). С помощью гиперссылки Сгенерировать пароль пользователь может использовать пароль, сформированный системой. Такой пароль будет удовлетворять всем установленным требованиям к паролям пользователей. Более подробно про пароль, формируемый системой, см. здесь.

Если указан адрес электронной почты, не соответствующий ни одному пользователю, то будет выдано диагностическое сообщение. Если пользователю запрещено восстанавливать пароль, то после ввода адреса электронной почты будет выдана ошибка.

В диалоге дополнительных настроек аутентификации также указываются следующие параметры:

● Длина кода ‑ указывается длина кода подтверждения установки нового пароля.

● Максимальное количество неуспешных попыток ввода ‑ указывает, сколько раз пользователь может ошибиться при вводе кода подтверждения. После превышения количества попыток ‑ полученный код становится недействителен. Пользователю необходимо запросить новый код восстановления пароля.

● Длительность блокировки запроса обновления кода подтверждения ‑ интервал времени, который должен разделять два идущих подряд запроса кода подтверждения смены пароля.

● Срок действия кода подтверждения ‑ определяет время действия высланного кода восстановления пароля. По истечении срока действия будет необходимо запросить новый код восстановления пароля.

● Использовать стандартный сервис отправки ‑ флажок позволяет отправлять письмо с кодом подтверждения через стандартный почтовый сервис фирмы «1С». В этом случае невозможно изменять отправителя, тему, формат и содержимое электронного письма. Письма всегда будут приходить с адреса 1C:Восстановление пароля <recoverypassword@1c.com>.

Если этот флажок сброшен, то появляется возможность настроить параметры отправки письма с кодом подтверждения. Эти параметры указываются в группе параметров Параметры отправителя.

В данной группе задаются параметры почтового сервера, через который будет выполняться отправка письма с кодом подтверждения, а также задаются параметры самого письма.

Параметры отправления задаются с помощью следующих параметров:

● Адрес сервера SMTP ‑ позволяет указать адрес SMTP-сервера.

● Пользователь SMTP и Пароль SMTP ‑ содержат имя пользователя и пароль, которые необходимы для аутентификации на SMTP-сервере.

● Порт SMTP ‑ сетевой порт, который используется для протокола SMTP:

● 465 порт ‑ для защищенных соединений (используется по умолчанию).

● 25 порт ‑ для незащищенных соединений.

● Использовать SSL ‑ указывает необходимость использования SSL для соединения с SMTP-сервером.

Параметры письма задаются с помощью следующих свойств:

● Имя отправителя ‑ текст, который будет отображаться в электронном письме в качестве автора письма (поле From).

● Заголовок сообщения ‑ текст, который будет указан в заголовке письма (поле Subject).

● Гиперссылка Текст сообщения ‑ позволяет открыть редактор HTML-документа, который позволит написать текст письма. В письме можно использовать следующие псевдопеременные для указания изменяющихся частей письма:

● ApplicationPeresentation ‑ представление конфигурации, которая используется в текущей информационной базе.

● UserName ‑ имя пользователя.

● UserPresentation ‑ полное имя пользователя.

● VerificationCode ‑ код подтверждения смены пароля.

В тексте письма значения переменных должны предваряться символом «&», например: Добрый день, &UserPresentation!.

Настройки восстановления пароля также доступны с помощью встроенного языка. Для этого предназначено свойства глобального контекста ДополнительныеНастройкиАутентификации.

Механизм проверки раскрытия пароля пользователя настраивается на закладке Проверка раскрытия пароля.

Рис. 68. Проверка раскрытия пароля

При самостоятельной смене или установке пароля пользователи склонны задавать простые пароли, широко известные пароли или пароли, которые можно легко подобрать. Чтобы предотвратить такую возможность, платформа «1С:Предприятие» предоставляет механизм проверки раскрытия паролей.

Настройки проверки раскрытия паролей выполняется в двух местах:

● Источники данных для механизма проверки настраиваются на закладке Проверка раскрытия паролей диалога Дополнительные настройки аутентификации (в описании которого мы сейчас находимся).

● Необходимость самой проверки и выполняемые действия настраиваются в параметрах информационной базы, а также в политиках паролей, которые назначены конкретным пользователям.

Всего доступно три различных канала проверки раскрытия, каждый из которых включается независимо (все каналы используются одновременно):

● Стандартный список платформы.

● Пользовательский список нежелательных паролей.

● Внешний сервис проверки раскрытия паролей.

Если установлен флажок Использовать стандартный список проверки раскрытия пароля, то выполнять проверку раскрытия пароля платформа будет по встроенному списку (который обновляется одновременно с изменением версии платформы). В этом случае информация о пароле не будет выходить за периметр информационной базы.

Если установлен флажок Использовать заданный список проверки раскрытия пароля, то для проверки будет использовать список нежелательных паролей, который может задаваться для каждой информационной базы индивидуально. Список задается или с помощью встроенного языка, или с помощью команд группы Список проверки раскрытия паролей. Команда Загрузить из файла позволяет загрузить список недопустимых паролей из файла. Команда Очистить выполняет очистку списка загруженных раскрытых паролей. Размер пользовательского списка недопустимых паролей ограничен значением 100 000.

Флажок Использовать сервис проверки раскрытия паролей позволяет указать, что для проверки раскрытия паролей будет использоваться специализированный HTTP-сервис. Поле Адрес сервиса позволит ввести адрес такого сервиса. Поле Таймаут запроса сервиса позволит указать, какой тайм-аут будет установлен для запроса к этому сервису (другими словами, максимальное время, которое платформа потратит на запрос к сервису проверки раскрытия паролей). Если запрос к сервису превысил установленный тайм-аут ‑ платформа считает, что запрос завершился с ошибкой. Если установлен флажок Игнорировать ошибки сервиса, то информация об ошибке записывается только в журнал регистрации и работа продолжается, как будто внешний сервис проверки раскрытия паролей отсутствует. Если флажок сброшен, то ошибка отображается пользователю и считается, что проверяемый пароль раскрыт.

Для обращения к сервису проверки раскрытия паролей используется GET-запрос вида <URL>/abcde, где:

● <URL> ‑ это значение, указанное в поле Адрес сервиса.

● abcde ‑ первые 5 символов значения хеша SHA-1 от проверяемого пароля («префикс» хеша).

Если сервис нашел у себя хеши, которые начинаются с указанного префикса, то все найденные хеши возвращаются вызывающей стороне. Затем вызывающая сторона ищет в результате работы сервиса оставшиеся символы от хеша. Если остаток найден ‑ значит пароль находится в списке раскрытых. Таким образом ‑ сервис не знает полный хеш проверяемого пароля и не может никаким образом восстановить пароль по переданному хешу. Очевидно, что такой сервис можно написать на платформе «1С:Предприятие». В этом случае наполнять базу, по которой выполняется проверка паролей, можно, во-первых, централизовано, а во-вторых, открывается возможность включать в этот список слова, которые запрещены (хотя сами эти слова вполне могут проходить проверку по «универсальной» базе проверки раскрытия паролей) в качестве паролей именно в той организации, которая реализовала этот сервис.

В качестве публично сервиса проверки раскрытия паролей можно указать, например, сервис «Have I Been Pwned» (https://haveibeenpwned.com/), который предоставляет HTTP-интерфейс с адресом https://api.pwnedpasswords.com/range/. Описание этого интерфейса приводится тут: https://haveibeenpwned.com/API/v3#SearchingPwnedPasswordsByRange (на английском языке). Платформа «1С:Предприятие» ожидает от сервиса проверки раскрытия паролей работу именно так, как описано по ссылке.

Собственно проверка раскрытия паролей (при условии корректной настройки механизма и его включения) выполняется в следующих случаях:

● Запись значения типа ПользовательИнформационнойБазы.

● Редактирование или создание пользователя в конфигураторе.

● Изменение пароля при восстановлении пароля пользователя.

● Изменение пароля в процессе аутентификации.

● Истек срок действия пароля.

● Был выявлен факт компрометации.

Проверка производится в том случае, если пароль прошел остальные проверки в соответствии с текущей политикой паролей. Если какая-либо проверка отключена, то она пропускается, а не отменяет остальные проверки.

Смотри также:

● Параметры информационной базы (см. здесь).

● Работа со списком проверки раскрытия паролей (см. здесь).

Для удаления пользователя следует в списке пользователей выделить его имя и выбрать пункт Действия ‑ Удалить окна Список пользователей.

Для подтверждения удаления пользователя в появившемся на экране запросе следует нажать Да.

Для редактирования параметров пользователя предназначен пункт Администрирование ‑ Пользователи меню конфигуратора. Выбрав нужного пользователя в списке, следует выбрать пункт Действия ‑ Изменить меню окна Список пользователей.

В окне Пользователь можно изменить параметры выбранного пользователя.

Для удобства просмотра списка пользователей можно использовать отбор. В списке пользователей выбирается пункт Действия ‑ Установить отбор…

Рис. 69. Установка отбора

Отбор можно выполнить по роли, языку, режиму запуска, а также с учетом аутентификации пользователя. Если в системе существуют разделители (общие реквизиты, для которых свойство Разделение данных установлено в значение Разделять), то отбор пользователей можно выполнять также по значениям разделителей.

Аутентификация ‑ проверка принадлежности предъявленного идентификатора (имени) конкретному пользователю системы, проверка подлинности. Система «1С:Предприятие» поддерживает несколько различных вариантов аутентификации, которые будут рассмотрены в следующих разделах. Следует отличать аутентификацию от авторизации. Авторизация ‑ предоставление определенному лицу или группе лиц прав на выполнение некоторых действий, а также процесс подтверждения этих прав при попытке выполнить это действие.

Пользователь может быть аутентифицирован системой «1С:Предприятие» с помощью ввода его имени и пароля (в диалоге аутентификации, в виде параметров командной строки или строки соединения с информационной базой для внешнего соединения или automation-сервера). В этом случае проверка наличия пользователя и корректности ввода его пароля выполняет система «1С:Предприятие».

Пользователь может быть аутентифицирован неявно средствами операционной системы. Для этого пользователю должен быть поставлен в соответствие некоторый пользователь операционной системы. При старте системы, «1С:Предприятие» запрашивает у операционной системы пользователя, который аутентифицирован в системе в данный момент. Для этого в ОС Windows используется интерфейс SSPI, а в ОС Linux ‑ GSS-API. Затем выполняется проверка, что данному пользователю операционной системы сопоставлен пользователь «1С:Предприятия». Если поиск заканчивается успешно ‑ считается, что пользователь системы «1С:Предприятие» аутентифицирован успешно, и диалог аутентификации не отображается.

Пользователь операционной системы указывается в формате: \\имя_домена\имя_пользователя. При этом имя пользователя не должно содержать символы алфавитов, отличных от латинского алфавита. Формат имени домена и имени пользователя может зависеть от настроек контроллера домена и учетных записей в нем. Определить правильное написание пользователя операционной системы можно по его представлению в событии CONN технологического журнала в свойстве Txt, которое начинается с текста Srvr: DstUserName2:. Например, событие 30:30.551013-0,CONN,2,process=rmngr,OSThread=24204,t:clientID=3,Txt=Srvr: DstUserName2: d1.d2\user1(d1.d2\user1) значит, что в качестве имени пользователя операционной системы в описании пользователя информационной базы должно быть указано \\d1.d2\user1.

Если необходимо принудительно выполнить аутентификацию средствами системы «1С:Предприятие», то в командной строке запуска клиентского приложения следует указать параметр командной строки /WA-. Соответственно, параметр командной строки /WA+ предназначен для принудительного применения аутентификации средствами операционной системы (действует по умолчанию).

Смотри также:

● Технологический журнал (см. здесь).

OpenID (https://openid.net/) ‑ это протокол, который позволяет пользователю использовать единую учетную запись для аутентификации на множестве не связанных друг с другом ресурсов, систем и т. д. Система «1С:Предприятие» использует протокол, созданный на основе протокола OpenID версии 2.0 по модели Direct Identity.

Общая схема работы выглядит следующим образом:

● Пользователь пытается выполнить вход в систему.

● Система определяет, что в информационной базе работает OpenID-аутентификация (по файлу публикации default.vrd).

● Провайдеру OpenID отправляется запрос на выполнение аутентификации. Очевидно, что OpenID-провайдер должен быть доступен для обращения с того адреса, на котором опубликована информационная база.

● Если необходимо выполнить интерактивное действие (выполняется первая аутентификация для данного идентификатора или истекло время жизни аутентификационных данных данного идентификатора), то провайдер сообщает системе о необходимости запросить имя и пароль пользователя. Система выполняет интерактивное действие и возвращает провайдеру OpenID запрошенные данные.

Аутентификационные данные пользователя хранятся в файлах cookie, которые размещаются в хранилище, индивидуальном для каждого веб-браузера. Тонкий клиент использует собственное хранилище.

● Если провайдер аутентифицирует пользователя, то системе возвращается признак того, что пользователь аутентифицирован.

OpenID-аутентификация работает только в тех случаях, когда доступ к информационной базе осуществляется по протоколу HTTP и HTTPS. Это означает, что использовать OpenID-аутентификацию могут только веб-клиент, мобильный клиент, а также тонкий клиент, подключенный к информационной базе через веб-сервер. При OpenID-аутентификации возможны кросс-доменные запросы при работе с помощью тонкого клиента, а также с помощью веб-браузеров Mozilla Firefox, Google Chrome и Safari.

В качестве OpenID-провайдера может выступать как информационная база «1С:Предприятия», опубликованная на веб-сервере специальным образом, а также произвольная информационная система, которая реализует работу по протоколу OpenID Authentication 2.0 и расширение этого протокола, реализованное в платформе «1С:Предприятие». Адрес используемого OpenID-провайдера следует указать в файле default.vrd (элемент <rely>) при публикации информационной базы, выступающей клиентом OpenID-провайдера.

Важно понимать, что «ключевым» полем, по которому обеспечивается сопоставление пользователя информационной базы «1С:Предприятия» и базы пользователей OpenID-провайдера, выступает значение, указанное в свойстве Имя пользователя информационной базы. Другими словами, пользователь сможет войти в информационную базу в том случае, если в информационной базе, в свойстве Имя будет указан идентификатор, возвращаемый OpenID-провайдером. Описание возвращаемого идентификатора необходимо получать в документации к используемому OpenID-провайдеру.

Пароль пользователя указывается в рамках OpenID-провайдера. Если в роли OpenID-провайдера выступает информационная база «1С:Предприятие», то пароль задается в информационной базе, выступающей в роли OpenID-провайдера. Пароль, заданный в информационной базе, которая является клиентом OpenID-провайдера, игнорируется при выполнении аутентификации с помощью OpenID. Если используется сторонний OpenID-провайдер, то пароль задается с помощью средств и инструментов этого провайдера. После того, как в хранилище пользователей OpenID-провайдера сменили пароль пользователя, система «1С:Предприятие» будет следовать следующим установкам:

● в текущих сеансах этот пользователь будет считаться аутентифицированным до завершения сеансов;

● при создании нового сеанса будет выполнен запрос пароля даже в том случае, если аутентификационные данные пользователя еще не устарели.

Если необходимо принудительно выполнить аутентификацию с помощью OpenID, то в командной строке запуска клиентского приложения следует указать параметр командной строки /OIDA+ (действует по умолчанию). Соответственно, параметр командной строки /OIDA‑ предназначен для принудительного отключения аутентификации с помощью OpenID.

Подробнее о настройке веб-сервера для работы с OpenID-аутентификацией см. здесь.

В настоящий момент при аутентификации с помощью OpenID, пользователю не отображается окно с требованием сменить пароль в следующих случаях:

● При истекшем сроке действия пароля.

● При скором истечении срока действия пароля.

● При несоответствии пароля требованиям во время аутентификации (при включенной настройке проверки надежности пароля).

Данное поведение вызвано тем, что аутентификация с помощь OpenID не поддерживаются данные механизмы.

Смотри также:

● OpenID Authentication 2.0 (см. https://openid.net/specs/openid-authentication-2_0.html).

● Дополнительные требования к OpenID-провайдеру (см. здесь).

OpenID Connect (https://openid.net/connect/) ‑ это протокол, который является расширением протокола аутентификации OAuth 2.0. OpenID Connect позволяет системе «1С:Предприятие» проверить личность пользователя на основе аутентификации, выполненной сторонним провайдером. Данный протокол применим при использовании тонкого клиента, мобильного клиента и веб-клиента. Система «1С:Предприятие» не может выступать в роли провайдера OpenID Connect. Для работы используются только внешние провайдеры. Поддержка протокола OpenID Connect также означает возможность использования Единой системы идентификации и аутентификации (ЕСИА).

Для сопоставления пользователя «1С:Предприятие» и пользователя провайдера аутентификации используются следующие данные:

● Со стороны провайдера аутентификации по умолчанию используется адрес электронной почты (как ключевой параметр). Во время настройки доступа к провайдеру OpenID Connect предоставляется возможность указать, какое поле токена аутентификации будет использоваться в качестве ключевого.

● Со стороны системы «1С:Предприятие» ключевой параметр по умолчанию находится в свойстве Имя пользователя информационной базы. Имеется возможность настроить систему таким образом, что в качестве ключевого поля будет выступать свойство ПользовательОС, АдресЭлектроннойПочты или значение из коллекции КлючиСопоставленияПользователя.

В том случае, когда для сопоставления будет использоваться коллекция КлючиСопоставленияПользователя, то ее заполнение можно выполнить только с помощью встроенного языка. Код может иметь следующий вид:

ПользовательИБ = ПользователиИнформационнойБазы.Найти(КодПользователя);
ПользовательИБ. КлючиСопоставленияПользователя.Вставить("googleIV", "user-name@google.com");
ПользовательИБ.Записать();

Элемент коллекции КлючиСопоставленияПользователя будет использован в том случае, если в списке провайдеров в файле default.vrd есть описание провайдера, у которого свойство name равно значению googleIV. Пользователь, который идентифицируется значением переменной КодПользователя, будет использован при запуске сеанса в том случае, если значение поля сопоставления из токена, который возвращает провайдер OpenID Connect, будет иметь значение user-name@google.com. Описание провайдера googleIV приведено в примере к элементу openidconnect.providers файла default.vrd.

Аутентификация OpenID Connect (в том числе и ЕСИА) поддерживается при работе в разделенной информационной базе. Значения разделителей будут использоваться для корректного определения аутентифицированного пользователя. Однако, для того чтобы значения разделителей использовались в системе, может потребоваться дополнительная настройка в файле default.vrd (параметр redirect_uri в описании провайдера).

При работе мобильного клиента аутентификация выполняется с использованием веб-браузера мобильного устройства:

● ОС Android: веб-браузер Google Chrome.

● ОС iOS: версия 9.0 и последующие.

В том случае, если мобильное устройство не соответствует вышеуказанным требованиям, пользователю может потребоваться заново выполнить аутентификацию на стороне провайдера OpenID Connect в мобильном клиенте. Для того чтобы принудительно выполнить аутентификацию при следующем входе, необходимо в мобильном клиенте выполнить команду Завершить работу.

Смотри также:

● Описание схемы работы с использованием провайдера OpenID Connect (см. здесь).

● Описание файла default.vrd (см. здесь).

Токен ‑ средство идентификации пользователя или отдельного сеанса работы в приложении. JSON Web Token (сокращенно JWT) ‑ стандарт создания токенов доступа, основанный на формате JSON. JWT описывается в стандарте RFC 7519 (https://datatracker.ietf.org/doc/html/rfc7519). JWT используется для аутентификации пользователя в клиент-серверных приложениях. Более подробно описание JWT (и использование этого механизма в прикладных решениях) см. здесь.

Аутентификация с помощью JWT работает только в тех информационной базах, которые опубликованы на веб-сервере. Для указания JWT используется команда командной строки запуска клиентского приложения AccessToken.

Опубликованная информационная база должна быть особым образом настроена. Настройка публикации производится с помощью файла default.vrd.

Для выполнения аутентификации в выбранной информационной базе с помощью JWT необходимо выполнить следующее:

1. Опубликовать информационную базу на веб-сервере.

2. Для пользователей, которые могут использовать JWT, необходимо указать свойство Аутентификация токеном доступа.

3. В файле default.vrd (опубликованной информационной базы) сформировать элемент accessTokenAuthentication с корректными параметрами. Необходимо учитывать следующее:

● Если поиск пользователя будет выполняться по полю, отличному от имени пользователя информационной базы, то следует указать значение атрибута authenticationUserPropertyName элемента issuer.

● Атрибут name элемента issuer.

● Подчиненный элемент accessTokenRecepientName должен содержать уникальное имя приложения, которое будет использовано при формировании JWT.

4. Подготовить для каждого пользователя токен доступа (с помощью объекта ТокенДоступа), в котором:

● Указать в качестве значения свойства Эмитент значение атрибуте name элемента issuer. Так будет сформирована претензия полезной нагрузки iss.

● Добавить в список получателей значение, которое указано в элементе accessTokenRecepientName файла default.vrd. Так будет сформирована претензия полезной нагрузки aud.

● Свойство КлючСопоставленияПользователя должен содержать значение ключевого поля для требуемого пользователя (в зависимости от значения, указанного в файле default.vrd в атрибуте authenticationUserPropertyName элемента issuer). Так будет сформирована претензия полезной нагрузки sub.

● Корректно заполнить остальные параметры токена и получить его (токена) строковое представление.

5. Строковое значение токена передать конкретному пользователю для указание в качестве значения параметра AccessToken при запуске клиентского приложения.

Смотри также:

● Описание работы с JWT (см. здесь).

● Файл default.vrd (см. здесь).

При использовании QR-кода используется следующая связка: мобильное приложение (мобильный клиент) в котором аутентифицирован пользователь, и другое клиентское приложение, которое тот же пользователь хочет использовать для доступа к той же информационной базе. В этом случае работа выполняется следующим образом: при необходимости аутентификации в информационной базе, пользователь должен с помощью мобильного приложения сканировать QR-код, который отображает клиентское приложение. Для успешного выполнения операции, пользователь, который выполняет попытку входа в другом клиентском приложении, уже должен быть аутентифицирован в мобильном приложении, причем в той же информационной базе, в какую он пытается войти в другом клиентском приложении.

Данная аутентификация возможна только в том случае, когда информационная база опубликована на веб-сервере и особым образом настроена. Настройка публикации производится с помощью файла default.vrd.

Аутентификация по QR-коду разделяется на два этапа:

● На мобильном устройстве отсутствует необходимое мобильное приложение.

● На мобильном устройстве установлено необходимое мобильное приложение.

Рассмотрим каждый из этих этапов более подробно:

● На мобильном устройстве отсутствует необходимое мобильное приложение:

● Пользователь пытается войти в информационную базу и в диалоге аутентификации выбирает вход по QR-коду.

● Клиентское приложение отображает QR-код, который нужно сканировать мобильным устройством.

● Пользователь использует любое доступное приложение для сканирования QR-кодов для того, чтобы сканировать представленный QR-код. После этого необходимо перейти по URL, который закодирован в коде.

● После перехода по ссылке, прикладное решение отображает ссылки на мобильные приложения, которые могут использоваться дал доступа к данной информационной базе (на разных мобильных операционных системах). Для настройки списка приложений используется элемент <mobileApps> в файле default.vrd.

● Пользователь выбирает и устанавливает нужное мобильное приложение.

● Пользователь переходит к этапу, когда на мобильном устройстве установлено нужное мобильное приложение.

● На мобильном устройстве установлено нужное мобильное приложение:

● Пользователь использует мобильное приложение для доступа к требуемой информационной базе.

● Пользователь хочет получить доступ к той же информационной базе с другого устройства. Для этого он запускает на другом устройстве клиентское приложение и выбирает вход по QR-коду в диалоге аутентификации.

● Пользователь в мобильном приложении выбирает пункт меню Главное меню ‑ Настройки и сервис ‑ Войти на другом устройстве и сканирует QR-код, предъявленный информационной базой на другом устройстве.

● Информационная база аутентифицирует новый сеанс пользователя.

В этом случае можно сказать, что аутентификация подтверждается владением мобильным устройством с мобильным приложением, в котором аутентифицирован пользователь.

Смотри также:

● Файл default.vrd (см. здесь).

Аутентификация через электронную почту является одним из видов беспарольной аутентификации. Для того, чтобы аутентифицироваться через электронную почту, пользователю необходимо выбрать этот вид аутентификации в диалоге выбора пользователя и затем ввести свой адрес электронной почты, который был указан при создании пользователя. В ответ система вышлет на указанный адрес письмо, в котором будет содержаться код подтверждения.

Присланный код подтверждения необходимо ввести в форму, которая откроется после того, как система отправит электронное письмо с кодом. Если код введен правильно, то пользователь проходит аутентификацию.

Для того, чтобы аутентификация через электронную почту работала, необходимо выполнить два действия:

● Настроить возможность такой аутентификации в диалоге Дополнительные настройки аутентификации.

● Включить для пользователя возможность аутентификации через электронную почту.

Необходимо помнить, что аутентификация через электронную почту не поддерживается для пакетного режима запуска и при отключении стартовых диалогов при запуске клиентского приложения.

Смотри также:

● Параметры пользователя (см. здесь).

● Диалог выбора пользователя (см. здесь).

● Дополнительные настройки аутентификации (см. здесь).

Аутентификацию пользователя платформа может выполнять самостоятельно, либо может воспользоваться результатами аутентификации, которую выполнил другой ресурс, которому она доверяет (операционная система или провайдер OpenID). В любом случае либо там, либо там пользователь указывает некоторый логин и вводит пароль. Если указана корректная пара логин/пароль, то платформа считает, что пользователь идентифицирован и предоставляет ему доступ к прикладному решению.

Эта привычная схема проста и удобна, но обладает одним существенным недостатком. Пароль надо помнить, для этого он должен быть коротким и простым. Но такой пароль легко взломать. Чтобы пароль было трудно взломать, он должен быть длинным и сложным. Но такой пароль непросто запомнить. По этой причине в реальности все сводится к тому, что люди используют простые пароли, причем в разных местах одни и те же.

Двухфакторная аутентификация ‑ это способ, позволяющий, с одной стороны, усложнить злоумышленникам доступ к чужим данным, а с другой стороны ‑ это решение, которое позволяет в какой-то степени нивелировать недостатки классической парольной защиты.

Двухфакторная аутентификация требует, чтобы пользователь имел два из трех возможных типов аутентификационных данных:

● Нечто ему известное, то, что он помнит. Это логин и пароль пользователя.

● Нечто, чем он владеет. Это может быть мобильный телефон или электронная почта пользователя.

● Нечто ему присущее. В этом качестве может выступать некоторая физическая особенность пользователя: отпечаток пальца, портрет, рисунок радужки глаза.

Смысл двухфакторной аутентификации заключается в том, что для того, чтобы получить доступ к прикладному решению, пользователь должен дважды подтвердить тот факт, что он ‑ это он, причем, разными способами. Например, ввести логин/пароль (и это будет первый фактор аутентификации), а затем ввести код, присланный на его мобильный телефон (и это будет второй фактор аутентификации).

Проверку первого фактора аутентификации выполняет сама платформа «1С:Предприятие», а для работы со вторым фактором аутентификации используется сторонний сервис, который будет называть провайдером второго фактора.

Провайдер второго фактора (в контексте данного раздела может использовать термин «провайдер») ‑ это HTTP-сервис, предоставляющий программный интерфейс для выполнения определенных действий. В роли провайдера второго фактора может выступать, например, информационная база «1С:Предприятия», в которой реализован набор HTTP-сервисов, позволяющих пересылать сообщения или выполнять аутентификацию. Это может быть сторонний сервис, пересылающий сообщения по SMS или электронной почте, это может быть сервис, генерирующий коды второго фактора аутентификации или сервис, взаимодействующий с пользователем через собственное мобильное приложение, и так далее. Важно лишь, что к провайдеру можно обращаться посредством HTTP-запросов.

Двухфакторную аутентификацию можно использовать только для аутентификации средствами системы «1С:Предприятие» (стандартная аутентификация), в любом варианте информационной базы и для любого клиентского приложения.

Смотри также:

● Аутентификация «1С:Предприятия» (см. здесь).

Итак, стандартная аутентификация системы «1С:Предприятие» (первый фактор) выглядит следующим образом:

● Пользователь запускает клиентское приложение. Клиентское приложение запрашивает у пользователя первый фактор аутентификации ‑ логин и пароль. Пользователь вводит их, клиентское приложение отправляет их на сервер.

● Сервер проверяет логин и пароль на корректность.

● Если указанные данные верны, то сервер проверяет, что для работы с прикладным решением пользователю достаточно указания одного фактора аутентификации. Если второй фактор использовать не нужно, то считается, что пользователь полностью идентифицирован и может начинать работу. Это привычный сценарий аутентификации.

Если для пользователя установлена двухфакторная аутентификация, то первые два шага выполняются, как и раньше ‑ указание логин/пароля и проверка этих данных серверов «1С:Предприятия».

Использование второго фактора может выполняться двумя способами:

● Сервер «1С:Предприятия» сам формирует второй фактор и сам проверяет корректность ввода значения этого фактора пользователем. Провайдер выполняет только транспортную функцию ‑ передачу значения второго фактора пользователю. При этом и сервер «1С:Предприятие» и пользователь знают, по какому каналу будет передано значение второго фактора.

Процесс выглядит следующим образом:

● Сервер «1С:Предприятие» сообщает клиентскому приложению, что пользователю необходимо указать второй фактор аутентификации.

● Клиентское приложение отображает форму ввода второго фактора.

● Сервер «1С:Предприятие» формирует и отсылает пользователю значение второго фактора (например, некоторое число), которое пользователь должен указать в форму, открытую клиентским приложением. Значение второго фактора может быть отправлено пользователю по электронной почте или с помощью SMS-сообщения.

● Пользователь получает данные второго фактора и вводит их в окно, открытое клиентским приложением. Клиентское приложение отправляет данные второго фактора на севере «1С:Предприятия».

● Сервер «1С:Предприятие» проверяет, что введенные данные совпадают с теми данными, которые были им (сервером) сформированы и отправлены пользователю.

● Если переданное клиентским приложением и сформированное сервером «1С:Предприятие» значения второго фактора совпали ‑ пользователь считается идентифицированным и ему предоставляется доступ к прикладному решению.

● Сервер «1С:Предприятия» использует сторонний сервис, который сообщает серверу «1С:Предприятие» результат применения второго фактора пользователем. В этом случае сервер «1С:Предприятие» не обладает знаниями, какой вид второго фактора будет использован. Способ передачи второго фактора пользователю также определяется выбранным провайдером второго фактора. Сервер «1С:Предприятие» обладает знанием только о том, что существует доверенный сервис, который в ответ на требование применить второй фактор аутентификации, сообщает ‑ успешно или неуспешно применен второй фактор.

Процесс выглядит следующим образом:

● Сервер «1С:Предприятия» сообщает клиентскому приложению о том, что пользователь должен выполнить аутентификацию второго фактора на стороне провайдера.

● Клиентское приложение показывает пользователю форму, в которой пользователь должен выполнить определенное действие после того, как пользователь пройдет аутентификацию провайдером второго фактора.

● Сервер отправляет HTTP-запрос провайдеру с просьбой аутентифицировать пользователя.

● Провайдер начинает процедуру аутентификации. Способ аутентификации остается на усмотрение провайдера.

● После окончания процедуры аутентификации, пользователь сообщает об этом клиентскому приложению.

● Клиентское приложение передает эту информацию серверу «1С:Предприятия», которое запрашивает провайдер второго фактора о результатах аутентификации.

● Провайдер сообщает серверу результат аутентификации. Если она выполнена успешно, то пользователь считается идентифицированным и ему предоставляется доступ к прикладному решению.

Каждый из рассмотренных в данном разделе способов имеет определенную поддержку со стороны системы «1С:Предприятие». Настройка применения второго фактора аутентификации рассмотрены в следующем разделе.

Настройка применения второго фактора в системе «1С:Предприятие» делится на несколько частей:

● Настройка шаблонов запросов, которые отправляются провайдерам.

● Привязка шаблона запроса к пользователю информационной базы.

● Параметризация запросов.

Подробнее рассмотрим каждую часть.

Для описания HTTP-запроса, который следует отправить провайдеру, используется объект ШаблонНастройкиВторогоФактораАутентификации. Выбор одного из вариантов второго фактора аутентификации осуществляется в процессе задания параметров шаблона. В том случае, когда надо реализовать первый вариант второго фактора аутентификации (сервер «1С:Предприятия» сам генерирует, отправляет и проверяет значение второго фактора), используются свойства HTTPЗапросНаАутентификацию и МетодHTTPЗапросаНаАутентификацию. Первое свойство содержит описание HTTP запроса (объект типа HTTPЗапрос), а второй параметр позволяет указать, какой HTTP-метод будет использоваться для запроса к провайдеру второго фактора аутентификации.

В том случае, когда надо реализовать второй вариант аутентификации (сервер «1С:Предприятия» только инициирует аутентификацию в провайдере второго фактора и получает ее результат), то рассмотренные выше параметры остаются и используются по прямому назначению ‑ начать использование второго фактора аутентификации. Для проверки результата аутентификации используются два дополнительных свойства: HTTPЗапросНаПроверкуРезультатаАутентификации и МетодHTTPЗапросаНаПроверкуРезультатаАутентификации.

Каждый шаблон имеет собственное имя (одноименное свойство), которое позволит идентифицировать шаблон при выполнении дальнейших действий.

Формируя HTTP-запроса (для задания любого свойства) следует помнить о следующих особенностях:

● HTTP-метод указывается в виде строки. Так сделано потому, что спецификация HTTP допускает использование собственных глаголов (методов).

● Текст запроса может содержать параметры. Параметры ‑ это некоторый текст, начинающийся с символа «&». Например, для указания имени пользователь можно использовать параметр &user_name. Эти параметры будут заменены на реальные значения в момент отправки запроса (будет рассмотрено ниже). Причиной такого решения служит предположение о том, что HTTP-запросы второго фактора аутентификации для разных пользователей будут практически одинаковыми. Отличия будут наблюдаться только в некоторой информации, которая специфична для конкретного пользователя. Например, условный запрос на отправку SMS-сообщения с кодом второго фактора будет выглядеть так: http://provider.example.com/sendsms/&phone_number. При отправке запроса параметр &phone_number будет необходимо заменить на фактический номер телефона пользователя.

Платформа предоставляет предопределенную переменную &secret, которая содержит значение второго фактора, сформированного платформой.

Обладая все информацией, посмотрим на пример создания шаблона для работы со вторым фактором по первому варианту (платформа формирует, отправляет, обеспечивает ввод и проверку второго фактора):

Запрос = Новый HTTPЗапрос;
Запрос.АдресРесурса = "&addr";
Запрос.УстановитьТелоИзСтроки("Введите значение &secret. Никому не говорите это значение!", "utf-8");
Провайдер = ШаблоныНастроекВторогоФактораАутентификации.СоздатьШаблон();
Провайдер.HTTPЗапросНаАутентификацию = Запрос;
Провайдер.МетодHTTPЗапросаНаАутентификацию = "POST";
Провайдер.Имя = "Запрос - ответ";
Провайдер.Записать();

Первые три строки формируют HTTP-запрос, который будет использоваться платформой. Остальные строки создают шаблон провайдера второго фактора, который будет отправлять запрос методом POST и иметь имя Запрос ‑ ответ.

Как, наверное, уже стало понятно, если необходимо сформировать шаблон провайдера второго фактора, работающего по второму варианту (все действия выполняются собственно провайдером, платформа только инициирует начало операции и запрашивает результат аутентификации), то вышеприведенный пример следует переработать таким образом, чтобы:

● Запрос на аутентификацию соответствовал требованиям используемого провайдера.

● Был сформирован (и задан в шаблоне) запрос на проверку результатов аутентификации. Этот запрос будет выполнен после того, как пользователь «сказал» клиентскому приложению, что он прошел аутентификацию у провайдера.

После того, как мы сохранили один или несколько шаблонов для провайдеров, появилась возможность назначить пользователю какой-либо из шаблонов. Следует помнить, что одному пользователю можно назначить несколько шаблонов и указать, как они будут обрабатываться.

Для задания настроек пользователя служат два свойства объекта ПользовательИнформационнойБазы:

● НастройкаВторогоФактораАутентификации ‑ сюда необходимо присвоить массив объектов типа НастройкаВторогоФактораАутентификации.

● ОбработкаНастроекВторогоФактораАутентификации ‑ описывает, что будет делать платформа, если задано несколько провайдеров второго фактора, и первый (по порядку обхода) провайдер вернул ошибку.

После указания вышеописанных свойств объект, описывающий пользователя информационной базы, следует записать.

Нам осталось рассмотреть последний момент: откуда платформа будет брать значения, которые будут подставляться вместо переменных в HTTP-запросах? Для этого подробнее рассмотрим объект НастройкаВторогоФактораАутентификации. Данный объект содержит два поля:

● ИмяШаблонаНастройки ‑ сюда следует указать имя шаблона настройки провайдера второго фактора, которое было указано в свойстве Имя при настройке шаблона провайдера.

● Параметры ‑ этому свойство необходимо присвоить соответствие. Соответствие должно содержать столько элементов, сколько параметров содержится в шаблоне настройки провайдера второго фактора (за исключением параметра &secret). Ключом элемента соответствия выступает имя параметра (без символа «&»), а значением ‑ значение переменной.

Теперь мы обладаем всей информацией для того, чтобы указать пользователю информационной базы необходимость выполнять двухфакторную аутентификацию при входе в информационную базу.

ПараметрыПровайдера = Новый Соответствие;
ПараметрыПровайдера.Вставить("addr", "http://example.com/resource");
НастройкаПользователя = Новый НастройкаВторогоФактораАутентификации;
НастройкаПользователя.ИмяШаблонаНастройки = "Вопрос - ответ";
НастройкаПользователя.Параметры = ПараметрыПровайдера;
НастройкиПользователя = Новый Массив;
НастройкиПользователя.Добавить(НастройкаПользователя);
Пользователь = ПользователиИнформационнойБазы.НайтиПоИмени("Продавец");
Пользователь.НастройкиВторогоФактораАутентификации = НастройкиПользователя;
Пользователь.ОбработкаНастроекВторогоФактораАутентификации = ТипОбработкиНастроекВторогоФактораАутентификации.ИспользоватьСледующийПриОшибке;
Пользователь.Записать();

Платформа будет заменять имена параметров на фактические значения в следующих свойствах:

● свойство HTTPЗапрос.АдресРесурса;

● свойство HTTPЗапрос.Заголовки;

● тело запроса объекта HTTPЗапрос (способ указания тела запроса не влияет не работу подстановки);

● свойство ШаблонНастройкиВторогоФактораАутентификации.МетодHTTPЗапросаНаАутентификацию;

● свойство ШаблонНастройкиВторогоФактораАутентификации.МетодHTTPЗапросаНаПроверкуРезультатаАутентификации.

Осталось упомянуть, что, если выбранный для пользователя провайдер второго фактора «сломался» ‑ пользователь не сможет получить доступ к информационной базе. В данном случае под термином «сломался» понимается любое событие, которое не позволяет провайдеру выполнить свою задачу: отсутствует Интернет для доступа от сервера к провайдеру, отсутствует Интернет для доступа от провайдера к пользователю, произошла ошибка на стороне провайдера и т. д.

Также необходимо понимать, что если вы планируете использовать сторонний провайдер второго фактора, то услуги этого провайдера могут быть платными и провайдер может выдвигать дополнительные условия и ограничения, которые лежат за пределами системы «1С:Предприятие» и не рассматриваются в данной документации.

Система программ «1С:Предприятие» поддерживает аутентификацию по протоколу OpenID. Если в информационной системе используется OpenID-аутентификация, то второй фактор должен запрашиваться OpenID-провайдером. Это справедливо, в том числе, если в качестве OpenID-провайдера указана информационная база системы «1С:Предприятие». Другими словами, двухфакторная аутентификация должна быть настроена в той информационной базе, которая выступает OpenID-провайдером.

На устройствах, имеющих средства биометрической аутентификации (датчик отпечатка пальцев, сканер лица, сканер радужки и т. д.), в диалогах настройки информационной базы мобильного клиента и в диалогах аутентификации (на мобильном устройстве) отображается флажок Использовать биометрию. Включение данного флажка приводит к использованию следующего механизма:

● После первого успешного входа, введенные имена пользователей и пароли информационной базы, аутентификации с помощью OpenID и веб-сервера помещаются в безопасное хранилище.

● При следующей попытке входа реализуется следующая логика:

● Сначала производится попытка входа без использования данных безопасного хранилища для проверки, что аутентификация в данный момент не требуется или имеются актуальные аутентификационные данные провайдера OpenID. Если на мобильном устройстве имеются актуальные аутентификационные данные, то запрос биометрических данных для подтверждения аутентификации будет выполнен только после истечения времени жизни аутентификационных данных.

● Если предыдущий шаг завершен неудачно, пользователю предлагается выполнить биометрическую аутентификацию, использую интерфейс мобильной операционной системы. Будет запрошен тот вид аутентификации, который указан в настройках мобильного устройства пользователя.

● Если пользователь отказался от биометрической аутентификации ‑ будет выполнен переход к диалогу стандартной аутентификации (с использованием имени пользователя и пароля).

● Если биометрические данные приняты мобильным устройством, из безопасного хранилища получаются данные, которые были запомнены в результате предыдущей успешной аутентификации. Полученные данные используются для аутентификации.

● Если биометрические данные устройством не принимаются, то данные предыдущей успешной аутентификации из безопасного хранилища удаляются. После этого выполняется переход к диалогу стандартной аутентификации (с использованием имени пользователя и пароля).

● Биометрия не может применяться при использовании аутентификации с помощью OpenID Connect, т. к. аутентификация выполняется на защищенной веб-странице провайдера OpenID Connect. Для этой страницы нельзя выполнить автоматическую подстановку сохраненного имени пользователя и пароля этого провайдера. Кроме того, OpenID Connect обеспечивает повторную аутентификацию на данном устройстве без ввода логина и пароля неограниченное время.

Если на мобильном устройстве поддерживается аутентификация с использованием OpenID Connect ‑ используется именно она. В случае отказа от аутентификации с помощью OpenID Connect ‑ появляется возможность использовать быстрый вход с использованием биометрии. Для попытки повторного использования аутентификации с помощью OpenID Connect должна произойти неудачная попытка входа.

В том случае, когда пользователю информационной базы назначены собственные роли из расширения (подробнее о расширениях конфигурации см. здесь), он (пользователь) отображается в списке специальной картинкой.

Рис. 70. Пользователю назначена роль из расширения

Роли, которые присутствуют в расширениях, подключенных к информационной базе, присутствуют в списке ролей, доступных для назначения пользователю. Роли расширений располагаются в конце списка ролей расширяемой конфигурации. Имеется возможность устанавливать или снимать отметки ролей расширений.

Рис. 71. Отображение ролей из расширения

В процессе работы бывает необходимо определить, какие пользователи работают в данный момент с информационной базой.

Для получения списка пользователей нужно выбрать пункт Администрирование ‑ Активные пользователи. На экран выводится окно со списком пользователей, работающих в данный момент с базой данных.

Рис. 72. Список активных пользователей

При открытии текущая строка показывает данные пользователя, открывшего форму (текущий сеанс). Текущий пользователь отличается в списке пиктограммой (имеет пометку на пиктограмме). Колонка Разделение данных содержит информацию о разделителях, указанную для пользователя в конфигураторе (закладка Разделение данных в свойствах пользователя). Эта колонка не содержит реальных значений разделителей, которые в момент открытия формы установлены в конкретном сеансе.

С помощью пунктов меню Действия можно настроить показ списка, а также вывести его в табличный или текстовый документ. Список активных пользователей можно сортировать по любой колонке.

При эксплуатации информационных систем возникает несколько ситуаций, в которых требуется управлять возможностью создания нового сеанса с информационными базами:

● Ограничение количества одновременно работающих пользователей с одной информационной базой.

● Обеспечение некоторого гарантированного запас лицензий при работе с информационной базой, например, при наличии 100 лицензий обеспечить гарантированную возможность доступа к информационной базе двух пользователей с фиксированными именами.

● Другие аналогичные задачи.

Для реализации этих задач предоставляется механизм внешнего управления сеансами. Для работы механизма необходимо наличие специализированного Web-сервиса, который занимается разрешением или запрещением создания сеанса. Механизм работает как с клиент-серверными, так и с файловыми информационными базами. Работа с файловой информационной базой поддерживается при одновременном выполнении следующих условий:

● Клиентское приложение системы «1С:Предприятие» версии 8.3.22 и последующих версий.

● Web-сервис внешнего управления сеансами версии 4 и последующих версий.

Предполагается следующая схема работы механизма:

● При попытке начать сеанс, система «1С:Предприятие» информирует Web-сервис о необходимости создания сеанса и передает в Web-сервис набор параметров, позволяющих определить все характеристики создаваемого сеанса (имя информационной базы, имя пользователя, IP-адрес клиентского приложения и т. д.).

● Web-сервис принимает решение о разрешении или запрещении создания сеанса и возвращает управление вызывающей стороне. При необходимости, Web-сервис может вести учет созданных сеансов в необходимых разрезах.

● При завершении сеанса, система «1С:Предприятие» также информирует Web-сервис о том, что сеанс завершается.

● Если сеанс переводится в состояние Спящий или выводится из этого состояния, то система «1С:Предприятие» информирует Web-сервис о каждом из этих событий. Данная возможность доступна только в том случае, если используется Web-сервис, который поддерживает протокол работы версии 2 и последующих версий.

Таким образом, система внешнего управления сеансами точно знает, какое количество сеансов сейчас создано в «подшефных» информационных базах и может принимать необходимые решения.

Сервис внешнего управления сеансами вызывается только для тех сеансов, которые для своей работы требуют клиентскую лицензию:

● конфигуратор,

● толстый клиент,

● внешнее соединение,

● тонкий клиент,

● веб-клиент,

● мобильный клиент,

● клиент системы 1С:Аналитика.

При старте других видов сеансов не происходит вызова сервиса внешнего управления сеансами.

Для настройки сервиса внешнего управления сеансами используется:

● В файловом враианте информационной базы ‑ конфигурационный файл conf.cfg (см. здесь).

● В клиент-серверном варианте информационной базы ‑ свойства информационной базы кластера серверов (см. здесь).

Описание самого Web-сервиса внешнего управления сеансами см. здесь.

Интерактивный способ

Система «1С:Предприятие» позволяет устанавливать блокировки сеансов пользователей с информационной базой. Можно запретить установку сеансов пользователей с информационной базой с отображением сообщения о причине запрета. Эта возможность полезна, например, когда для выполнения административных действий требуется, чтобы текущие пользователи завершили свои сеансы работы и в то же время новые пользователи не могли подключиться к информационной базе.

При работе в клиент-серверном варианте работы установка блокировки может быть выполнена с помощью утилиты администрирования кластера серверов «1С:Предприятия» (подробнее см. здесь).

Предусмотрена возможность соединения с информационной базой в обход установленной блокировки сеансов. Для этого используется параметр командной строки UC и параметр строки соединения UC. Если при установке блокировки задан непустой код разрешения, то для установки соединения в обход блокировки необходимо в параметре UC указать этот код разрешения. Если код разрешения содержит пробелы, он должен быть заключен в кавычки.

Если используется веб-клиент или тонкий клиент, работающий через веб-сервер, то кроме указания параметра UC в командной строке запуска, имеется возможность указания кода разрешения в параметре UC строки соединения файла-дескриптора (см. здесь). В этом случае рекомендуется выполнять дополнительную публикацию информационной базы на веб-сервере.

Так, если установлена блокировка начала сеансов и код разрешения установлен в значение 123, то для начала сеанса в обход установленной блокировки необходимо указать в командной строке запуска клиентского приложения строку /UC123.

Программный способ

Кроме этого, при работе в любом режиме информационной базы, установка блокировки начала сеансов может быть выполнена средствами встроенного языка. Для этого используется объект встроенного языка БлокировкаСеансов, который можно создать с помощью конструктора и установить необходимые свойства блокировки установки соединений. Сообщение, которое можно задать для показа пользователю (с помощью свойства БлокировкаСеансов.Сообщение), может быть задано как простой текстовой строкой, так и форматированной строкой.

Метод глобального контекста УстановитьБлокировкуСеансов() позволяет установить созданную блокировку, а метод ПолучитьБлокировкуСеансов() ‑ получить установленную блокировку.

Одним из способов получения несанкционированного доступа к данным информационной базы является подбор пароля пользователя. В этом случае злоумышленник перебирает пароли по какому-то алгоритму до тех пор, пока не подберет нужный пароль для выбранного пользователя. Чтобы затруднить такой подбор, система «1С:Предприятие» предлагает специальный механизм, который работает только в клиент-серверном варианте информационной базы.

Администратор управляет работой механизма путем настройки следующих параметров информационной базы (диалог доступен с помощью команды Главное меню ‑ Администрирование ‑ Параметры информационной базы):

● Максимальное количество неуспешных попыток аутентификации ‑ определяет, сколько раз пользователь может ввести неверный пароль перед блокировкой попыток входа. Блокировка сработает при N-й неудачной попытке аутентификации подряд, где N ‑ это значение данного параметра. Другими словами, если параметр установлен в значение 3, то пользователь будет заблокирован после 3 неудачной попытки аутентификации. Информация о блокировке будет отображаться пользователю, начиная N+1 попытки аутентификации.

Если этот параметр установлен в значение 0, то механизм отключается, и контроль над количеством неудачных попыток аутентификации платформой не выполняется.

● Длительность блокировки при превышении количества неудачных попыток аутентификации (в секундах) ‑ определяет, в течение какого времени пользователь не сможет выполнить попытку аутентификации, если он ввел неверный пароль столько раз, сколько определено параметром Максимальное количество неуспешных попыток аутентификации.

● Коды дополнения имен пользователя при блокировке аутентификации ‑ позволяет выполнить еще блок попыток аутентификации для заблокированного пользователя. Коды дополнения разделяются символом «;». В этом случае пользователь образуется из реального имени заблокированного пользователя и одного из указанных кодов дополнения. Для пользователя, образованного с помощью кода дополнения, предоставляется столько же попыток, сколько и для обычного пользователя. После исчерпания попыток аутентификации «дополнительный» пользователь также будет заблокирован.

Механизм работает следующим образом:

● Злоумышленник вводит имя пользователя и начинает подбирать пароль, вводя какой-то предполагаемый пароль пользователя. После того, как срабатывает ограничение на максимальное количество ошибок аутентификации ‑ имя пользователя, которое использует злоумышленник, блокируется системой.

● Если заблокированный пользователь попытается войти под своим именем и со своим паролем ‑ он получит сообщение о том, что пользователь заблокирован.

● В том случае, если в базе настроены коды дополнения, пользователь может воспользоваться одним из кодов дополнения. Для этого ему необходимо ввести свое имя, дополненное кодом дополнения. При работе с кодом дополнения необходимо учитывать следующее: анализ кода дополнения начинается только в том случае, если введенное имя пользователя не находится в списке пользователей информационной базы. У такого имени вычитаются последовательно все, указанные в настройках, коды дополнения имен и проверяется наличие пользователя информационной базы с таким именем. Из этого описания следует простое следствие: не рекомендуется создавать коды дополнения, которые совпадают с окончанием имени реального пользователя. Если такого пользователя заблокирует рассматриваемый механизм, войти с помощью код дополнения он не сможет. Следующим следствием является рекомендация начинать код дополнения с различных «технических» символов, которые не могут оказаться в имени пользователя, например «!», «^» и т. д.

Для просмотра списка заблокированных пользователей можно воспользоваться формой, которая доступна в конфигураторе с помощью команды Главное меню ‑ Администрирование ‑ Блокировки аутентификации. Форма доступна пользователю, у которого имеется право Администрирование или АдминистрированиеДанных. Информация о блокировках пользователей доступна в журнале регистрации.

Информация о заблокированных пользователях хранится сервисом вспомогательных функций кластера серверов. Это означает что:

● Если заблокирован единственный администратор, то для того, чтобы войти под таким пользователем во время блокировки ‑ необходимо перезапустить кластер серверов.

● Счетчик ошибочных попыток входа ведется от момента последней успешной попытки входа и не имеет срока давности. Однако перезапуск кластера серверов сбрасывает все счетчики для всех пользователей информационной базы.

Управление механизмом блокировок выполняется с помощью объекта глобального контекста БлокировкаАутентификации. С помощью этого объекта можно изменять настройки механизма (с помощью методов ПолучитьНастройки()/УстановитьНастройки()). Также доступно получения списка текущих блокировок с помощью метода ПолучитьБлокировки().

С помощью встроенного языка можно принудительно разблокировать всех (или избранных) заблокированных пользователей. Для этого необходимо получить список текущих блокировок, который будет представлен массивом объектов БлокировкаАутентификацииПользователяИнформационнойБазы. Затем определить список тех пользователей, которых следует разблокировать (на основании свойств объекта БлокировкаАутентификацииПользователяИнформационнойБазы). Затем для выбранных заблокированных пользователей следует вызвать метод Разблокировать() этого же объекта.

В процессе работы могут возникать задачи отключения пользователя, который некоторый промежуток времени не выполняет интерактивных действий в информационной базе. Это потребность может быть вызвана как необходимостью эффективного использования лицензий, так и с целью снижения вероятности несанкционированного доступа к данным информационной базы. Платформа «1С:Предприятие» предоставляет механизм для завершения сеанса работы с информационной базой при бездействии пользователя.

Для этого в списке параметров информационной базы следует указать значения для двух параметров:

● Время завершения сеанса при бездействии. Этот параметр позволяет указать интервал времени, по истечении которого сеанс будет завершен, если пользователь не проявлял активности.

● Время предупреждения о завершении сеанса при бездействии. Данный параметр указывает, через какой интервал времени пользователя следует предупредить о том, что его сеанс будет автоматически завершен, если он (пользователь) не возобновит работу в сеансе.

Данные параметры используются только с клиентскими сеансами в следующих приложениях: тонком, толстом, мобильном клиенте и мобильном приложении. Сеанс Конфигуратор не может быть завершен таким образом.

В зависимости от вида клиентского приложения, под понятием «пользовательская активность» понимается:

● Тонкий и толстый клиент: нажатия клавиш, движение мыши в окне приложения, участие в видеоконференции системы взаимодействия.

● Мобильный клиент и мобильное приложение: нажатие экранных кнопок, прокрутка форм и касания различных частей форм.

В диалоге предупреждения о бездействии отображается таймер обратного отсчета, после которого сеанс будет завершен. При этом приложение завершено не будет, а на экране будет отображен диалог с информацией о том, что работа приложения завершена из-за неактивности пользователя и предложением завершить работу или перезапустить клиентское приложение.

Не рекомендуется одновременно включать возможность сохранения аутентификации и завершение сеанса при бездействии, если завершение сеанса при бездействии включается для минимизации рисков несанкционированного доступа к данным. В этом случае принудительное завершение сеанса не защитит от несанкционированного доступа, т. к. данные с помощью сохраненной аутентификации злоумышленник все равно сможет получить доступ к данным информационной базы.

Смотри также:

● Параметры информационной базы (см. здесь).

● Сохранение аутентификации (см. здесь).

Режим настройки региональных установок информационной базы позволяет управлять форматом отображения даты, времени, чисел, логических констант и влияет на порядок сортировки строк в списках информационной базы данных. Для вызова режима нужно выбрать пункт Администрирование ‑ Региональные установки ИБ.

Рис. 73. Региональные установки

Если какое-либо свойство не установлено, то форматы отображения чисел, даты и времени будут определяться установками по умолчанию, принятыми в системе «1С:Предприятие» для указанного языка (страны). Язык (страна) определены при создании информационной базы.

Язык (Страна). Выбор языка (страны) для данной установки информационной базы.

С помощью свойства Первый день недели можно указать, с какого дня начинается неделя в соответствии с культурными особенностями страны. Если выбрано Авто, то первый день недели выбирается в соответствии с тем, какая страна указана в свойстве Язык (Страна). Так, при выборе языка английский, первый день недели будет установлен Воскресенье, для языка арабский, первым днем недели будет установлена Суббота. В качестве первого также можно выбрать любой день недели.

В информационной базе, созданной с помощью «1С:Предприятия» версии 8.3.6 и ниже, значение первого дня недели не хранится в информационной базе. При этом если для прикладного решения, развернутого в данной информационной базе, действует режим совместимости с версией 8.3.6 и младше, то в качестве первого дня недели будет использоваться Понедельник (без возможности изменения). Описание режимов совместимости см. здесь. Если режим совместимости (для такой информационной базы) будет установлен в значение Не используется (или версия совместимости будет строго старше 8.3.6), то первый день недели будет определяться по значению свойства Язык (Страна). Также будет считаться, что свойство Первый день недели установлено в значение Авто.

В информационной базе, созданной с помощью «1С:Предприятия» версии 8.3.7 и старше, значение первого дня недели хранится в информационной базе. При этом в момент создания информационной базы свойство Первый день недели устанавливается в значение Авто. Значение свойства может быть изменено и будет сохранено в информационной базе. Установка для этой информационной базы режима совместимости с версией 8.3.6 и младше, приведет к тому, что в качестве первого дня недели будет выбран Понедельник и свойство Первый день недели будет невозможно редактировать. Однако реальная настройка будет сохранена и станет действующей при установке режима совместимости в значение Не использовать (или если версия совместимости будет строго старше 8.3.6). Попытка отредактировать региональные настройки с помощью «1С:Предприятие» версии 8.3.6 и младше, приведет к тому, что значение свойства Первый день недели будет утеряно.

Если установлено свойство Использовать региональные установки текущего сеанса, то значения типа Число и Дата отображаются (в том числе в полях ввода, календаре и калькуляторе) в соответствии с региональными настройками текущего сеанса. Эти настройки определяются на основании региональных установок клиентского компьютера, но могут быть переопределены параметром /VL.

В нижней части диалога выводятся примеры отображения числа, даты и времени с выбранными в диалоге установками.

Значения типа Булево отображаются в соответствии с языком интерфейса платформы. Это значение может быть указано с помощью параметра /L.

Разделитель дробной части. Символ-разделитель целой и дробной части чисел можно выбрать из выпадающего списка или указать самостоятельно в поле ввода. Пример символа будет выведен в рамке слева от поля ввода.

Разделитель групп. Символ-разделитель групп цифр в целой части числа можно выбрать из выпадающего списка или указать самостоятельно в поле ввода. Пример символа будет выведен в рамке слева от поля ввода.

Группировка. Свойство задает формат группировки цифр в целой части числа. Форматную строку можно выбрать из выпадающего списка или указать самостоятельно. Формат группировки указывается следующим образом: <A><символ-разделитель><B>. В качестве символа-разделителя можно использовать любой символ, отличный от цифры. Форматная строка позволяет задать одну или две группы цифр, считая справа налево. Каждый из символов (A и B) указывает количество цифр в своей группе.

Рассмотрим примеры форматных строк на числе 987654321, когда разделителем групп будет выступать символ «/». Описание также идет «справа-налево»:

● Группировка ‑ 3,2, представление ‑ 98/76/54/321:

● первую группу образуют первые три цифры числа;

● затем идет символ-разделитель групп (заданный настройками операционной системы или указанный в свойстве Разделитель групп);

● все оставшиеся цифры числа будут сгруппированы по две.

● Группировка ‑ 3,0, представление ‑ 987/654/321:

● в каждой группе по 3 цифры;

● между группами символ-разделитель групп.

● Группировка ‑ 4, представление ‑ 98765/4321:

● первую группу образуют 4 цифры;

● между группами размещается символ-разделитель групп;

● все остальные цифры числа идут без группировки и разделителей.

Представление отрицательных чисел. Из выпадающего списка можно выбрать вид отрицательных чисел. Выбор Авто означает, что вид отрицательных чисел будет определяться установками операционной системы.

Формат даты. Устанавливает формат отображения даты. Можно использовать в различных сочетаниях следующие символы:

Перечисленные выше символы и группы символов можно указывать в любой последовательности. Для разделения дня, месяца и года можно указывать различные символы-разделители.

Формат времени. Устанавливает формат отображения времени. Можно использовать в различных сочетаниях следующие символы:

Перечисленные выше символы и группы символов можно указывать в любой последовательности. Для разделения часов, минут и секунд можно указывать различные символы-разделители.

Логическое ложь. Логическое истина. Позволяет указать вид логических констант. Можно выбрать из выпадающего списка либо ввести самостоятельно.

Смотри также:

● Конвертация значений в строку и обратно (см. здесь).

Режим настройки параметров информационной базы позволяет задавать следующий набор параметров:

● настраивать параметры аутентификации,

● задание требования к паролям пользователей,

● время ожидания блокировки данных,

● параметры работы с пассивными сеансами,

● количество заданий пересчета итогов,

● настраивать поведение, связанное с подписью мобильного клиента.

Эти параметры находятся в диалоге Параметры информационной базы, который доступен с помощью команды Главное меню ‑ Администрирование ‑ Параметры информационной базы.

На данной закладке выполняется настройка параметров аутентификации пользователей.

Рис. 74. Параметры информационной базы. Аутентификация пользователей

Параметры аутентификации разделены на две группы: общие параметры и параметры, которые описываются политикой паролей.

К общим можно отнести следующие параметры (группа «Аутентификация»):

Подробное описание работы с параметром см. здесь.

Подробное описание работы с параметром см. здесь.

Подробное описание работы с параметром см. здесь.

Пароли пользователей хранятся в информационной базе не в открытом виде, а виде результата выполнения хеш-функции, которая препятствует восстановлению исходного значения пароля. В результате даже получив доступ к списку пользователей информационной базы, злоумышленник не сможет увидеть пароли в явном виде. Платформа поддерживает несколько хеш-функций (алгоритмов хеширования), которые могут использоваться для хеширования паролей: SHA-1, SHA-256, SHA-512 и PBKDF2-SHA256. Выбирая хеш-функцию для паролей, следует учитывать следующее:

● Если необходимо, чтобы к информационной базе могли иметь доступ из любой версии системы «1С:Предприятие», следует использовать алгоритм SHA-1.

● Если доступ к информационной базе будет осуществляться из системы «1С:Предприятие» версии 8.3.26 и последующих ‑ можно использовать любую хеш-функцию. Все последующие замечания имеют смысл только для того случая, когда доступ к информационной базе выполняется из версии 8.3.26 и последующих версий.

● Если необходимо использовать алгоритм, максимально затрудняющий подбор пароля перебором ‑ следует использовать алгоритм PBKDF2-SHA256, при этом дополнительно обеспечив защиту информационной базы от DOS/DDOS-атаки (denied of service, отказ в обслуживании). Эта рекомендация обусловлена тем, что алгоритм PBKDF2-SHA256 работает примерно в 2 000 раз медленнее, чем алгоритм SHA-1. Если попытаться обеспечить подбор пароля большим количество соединений ‑ это заставить кластер серверов «1С:Предприятие» заниматься только подсчетом значений хеш-функций паролей для проверки возможности аутентификации.

● Если принять за 1 скорость работы алгоритма SHA-1, то алгоритм SHA-256 имеет скорость 2*SHA-1, алгоритм SHA-512 имеет скорость 3*SHA-1, а PBKDF2-SHA256 имеет скорость 1915*SHA-1.

Для изменения алгоритма хеширования паролей информационной базы можно воспользоваться одним из диалогов интерактивной настройки параметров информационной базы (в конфигураторе или из стандартных функций) или использовать методы глобального контекста ПолучитьТипАлгоритмаХешированияПаролейПользователей()/УстановитьТипАлгоритмаХешированияПаролейПользователей(). Для того, чтобы определить, какая хеш-функция используется для пароля конкретного пользователя информационной базы, следует использовать свойство ПользовательИнформационнойБазы.ТипАлгоритмаХешированияПароля. Для всех алгоритмов хеширования, кроме SHA-1, во время хеширования к паролю добавляется «соль». «Солью» называется произвольная и случайная строка данных, которая добавляется к хешируемому паролю для того, чтобы исключить ситуацию, когда для одного набора входных данных (пароль) формируется одинаковый хеш. «Соль» изменяется при каждой смене пароля и для каждого пользователя.

Для смены алгоритма хеширования паролей следует использовать следующую последовательность действий:

● Администратор изменяет алгоритм хеширования пароля одним из доступных способов.

● Администратор завершает все активные сеансы пользователей информационной базы для того, чтобы все пользователи заново прошли процедуру аутентификации.

● Во время аутентификации пользователи заново вводят свой пароль, который хешируется по новому алгоритму. Новое значение хеш-функции записывается в соответствующий объект ПользовательИнформационнойБазы (вместе с новым алгоритмом хеш-функции).

● По истечение некоторого времени, например, 1 месяц, администратор может проверить пользователей, у которых остался алгоритм хеширования паролей, который был до момента смены алгоритма, и для этих пользователей принудительно сменить пароли и разослать новые пароли с помощью электронной почты. Выполнить это можно с помощью встроенного языка.

Если у каких-то пользователей информационной базы были запомнены параметры аутентификации, то после смены хеш-функции все выпущенные токены станут недействительными и пользователю будет необходимо повторить аутентификацию в информационной базе с установленным флажком Запомнить.

Группа Требования к паролям описывает набор параметров, которые могут применяться как для информационной базы в целом, так и для конкретных пользователей. Описание работы с политиками паролей см. здесь.

Смотри также:

● Параметры пользователя информационной базы (см. здесь).

● Политики паролей пользователей (см. здесь).

● Аутентификация пользователя информационной базы (см. здесь).

На данной закладке находятся параметры работы с информационной базы и настройка поведения конфигуратора при работе с подписью мобильного клиента.

Рис. 75. Параметры информационной базы. Прочие

Определяет максимальное время ожидания установки транзакционной блокировки сервером баз данных. Например, если текущая транзакция должна установить блокировку на запись, а запись уже заблокирована другой транзакцией, то текущая транзакция будет ожидать снятия блокировки, но не дольше, чем значение данного параметра. Аналогичным образом этот параметр регулирует время ожидания транзакционной блокировки в режиме управляемых блокировок системы «1С:Предприятие».

Изменение данного параметра (из данного диалога или из встроенного языка) требует административных прав и устанавливает монопольный режим доступа к информационной базе.

Изменение времени ожидания блокировки данных действует сразу после выполнения для всех СУБД, кроме IBM Db2. На IBM Db2 после изменения времени ожидания блокировки данных требуется рестарт СУБД.

Для доступа из встроенного языка используются методы ПолучитьВремяОжиданияБлокировкиДанных()/УстановитьВремяОжиданияБлокировкиДанных().

Сеанс, не проявляющий активности на протяжении указанного времени, переводится в состояние Спящий. Более подробно о сеансах см. здесь.

До выполнения аутентификации пользователя, сеанс переводится в состояние Спящий не более, чем через 20 секунд отсутствия активности клиентского приложения.

Для доступа из встроенного языка используются методы ПолучитьВремяЗасыпанияПассивногоСеанса()/УстановитьВремяЗасыпанияПассивногоСеанса().

Спящий сеанс уничтожается по истечении указанного интервала времени. Более подробно о сеансах см. здесь.

До выполнения аутентификации пользователя, спящий сеанс уничтожается не позднее, чем через 20 минут.

Для доступа из встроенного языка используются методы ПолучитьВремяЗавершенияСпящегоСеанса()/УстановитьВремяЗавершенияСпящегоСеанса().

Определяет количество системных фоновых заданий, которые будут использоваться для пересчета итогов регистров при выполнении операций реструктуризации информационной базы или выполнении тестирования и исправления. Значение по умолчанию равно 4, т. е. для пересчета итогов одновременно будут запущены 4 фоновых задания. Параметр применяется только для клиент-серверного варианта информационной базы.

Если в сеансе пользователя отсутствует какая-либо активность, то через указанный интервал времени будет отображен диалог с информацией о том, что сеанс будет завершен. В диалоге можно выбрать вариант продолжения работы (не завершать сеанс). Значение, равное 0, отключает отображение предупреждения.

Для доступа из встроенного языка используются методы ПолучитьВремяПредупрежденияОЗавершенииСеансаПриБездействии()/УстановитьВремяПредупрежденияОЗавершенииСеансаПриБездействии().

Подробнее об автоматическом завершении сеансов см. здесь.

Сеанс пользователя, в котором отсутствует активность, будет завершен по истечении указанного интервала времени. Значение, равное 0, отключает механизм принудительного завершения сеанса пользователя.

Для доступа из встроенного языка используются методы ПолучитьВремяЗавершенияСеансаПриБездействии()/УстановитьВремяЗавершенияСеансаПриБездействии().

Подробнее об автоматическом завершении сеансов см. здесь.

Включает использование дополнительных индексов в информационной базы.

Для доступа из встроенного языка используются методы УстановитьИспользованиеДополнительныхИндексов()/ПолучитьИспользованиеДополнительныхИндексов().

Подробнее о дополнительных индексах см. здесь.

Подробное описание работы с параметром см. здесь.

Некоторые параметры информационной базы можно изменять и получать только с помощью встроенного языка. К таким параметрам относятся:

● Часовой пояс информационной базы ‑ ПолучитьЧасовойПоясИнформационнойБазы()/УстановитьЧасовойПоясИнформационнойБазы().

● Год начала столетия ‑ ПолучитьНачалоСтолетияИнформационнойБазы()/УстановитьНачалоСтолетияИнформационнойБазы()/НачалоСтолетияСеанса().

Параметр используется в тех случаях, когда необходимо определить целый год даты по последним двум цифрам. Когда год начала столетия установлен в значение «1950» (значение по умолчанию), то цифры года «49» будут соответствовать году «2049», а цифры года «50» будут соответствовать году «1950».

Если параметры информационной базы устанавливаются в транзакции, то метод получения параметра, установленного таким образом, будет возвращать:

● В текущем сеансе:

● до конца транзакции ‑ последнее установленное значение;

● после фиксации транзакции ‑ последнее установленное значение;

● после отмены транзакции ‑ значение на момент начала транзакции.

● В другом сеансе:

● Вне транзакции для блокировочных СУБД (Microsoft SQL Server, IBM Db2) ‑ последнее установленное значение не позднее чем через 20 секунд после установки значения. При отмене транзакции ‑ значение на момент начала транзакции не позднее, чем через 20 секунд после отмены.

● В транзакции и для версионных СУБД (файловая версия, PostgreSQL, Oracle Database) ‑ последнее установленное значение не позднее чем через 20 секунд после фиксации транзакции, в которой значение было установлено.

В клиент-серверном варианте информационной базы установка значения параметра из клиентского кода толстого клиента сразу видна в серверном коде и наоборот.

Текущую информационную базу можно сохранить в файл на диске. Для сохранения данных в файл нужно выбрать пункт Администрирование ‑ Выгрузить информационную базу данных в файл. На экран выводится стандартный диалог выбора файла. Следует выбрать каталог и указать имя файла, в который будут записаны данные.

В файл выгрузки попадут все данные самой информационной базы, а также данные всех подключенных хранилищ двоичных данных. Данные хранилища двоичных данных будут включены в состав выгрузки в том случае, если выгрузка выполняется из клиент-серверного варианта информационной базы и для этой базы создано хранилище двоичных данных.

Механизм выгрузки предназначен:

● для получения образа информационной базы независимо от способа хранения данных;

● для переноса информационной базы из одной СУБД (или файлового варианта) в другую СУБД (или в файловый вариант).

Перед выполнением выгрузки информационной базы рекомендуется выполнить процедуру тестирования (средствами конфигуратора или отдельной утилиты) и исправить все обнаруженные проблемы.

Не рекомендуется использовать данный способ для создания резервной копии информационной базы по следующим причинам:

● может возникнуть ситуация, при которой файл выгрузки будет невозможно загрузить, если в информационной базе, из которой производилась выгрузка, существовали ошибки;

● длительное время создания;

● необходимость монопольного доступа к базе данных;

● высокие требования к оперативной памяти.

Смотри также:

● Хранилище двоичных данных (см. здесь).

Для восстановления информационной базы из файла используется пункт Администрирование ‑ Загрузить информационную базу данных из файла.

На экран выводится стандартный диалог выбора файла. Необходимо выбрать каталог и указать имя файла, в который будут записаны данные.

При загрузке информационной базы из файла, необходимо обеспечить наличие свободного дискового пространства (под временные файлы) в объеме, примерно равного объему загружаемой информационной базы в развернутом состоянии:

● Для файлового варианта ‑ на компьютере, где выполняется загрузка информационной базы из файла.

● Для клиент-серверного варианта ‑ на компьютере сервера «1С:Предприятия».

Размер получившейся базы данных может в несколько раз превышать размер файла .dt, из которого выполняется загрузка.

Для ускорения процесса загрузки информационной базы, при использовании СУБД Microsoft SQL Server, рекомендуется режим восстановления для базы данных устанавливать в значение Простой или С неполным протоколированием. Смену режима можно выполнять или перед выполнением загрузки или на постоянной основе, если не требуется выполнять восстановление базы данных на произвольный момент времени. Перед сменой режима восстановления базы данных необходимо выполнить резервное копирование базы данных.

Файл выгрузки информационной базы (.dt), созданный «1С:Предприятием» версий 8.1 и 8.2, может быть загружен «1С:Предприятием» версии 8.3. При попытке загрузить конфигурацию с неизвестным режимом совместимости, будет выдаваться ошибка с указанием требуемой версии. Запрещена загрузка файлов 1cv8.dt, сформированных в версии 8.3.1 и выше, в «1С:Предприятии» младших версий (младше версии 8.3.1). Исключением является ситуация, когда в версии 8.3.1 и выше свойство конфигурации Режим совместимости установлено в значение Версия 8.2.16.

Создание резервной копии осуществляется в любой программе, поддерживающей работу с файлами. С помощью программы работы с файлами необходимо открыть каталог с информационной базой. Для создания копии информационной базы необходимо просто скопировать файл 1Сv8.1CD в отдельный каталог. Для восстановления (в случае утери, порчи и т. д.) информационной базы достаточно скопировать сохраненный файл в прежний каталог.

Заметим, что для копирования информационной базы также можно использовать специализированное программное обеспечение, предназначенное для резервного копирования и восстановления данных.

Для повышения информативности резервной копии, рекомендуется включать в ее состав также файлы журнала регистрации (подробнее см. здесь), которые хранятся в каталоге 1Cv8Log каталога информационной базы. В этом случае восстановление информационной базы также желательно выполнять совместно с журналом регистрации (каталогом 1Cv8Log). В этом случае станет доступна информация по всем действиям, которые были выполнены в информационной базе до момента резервной копии.

Резервное копирование информационной базы в клиент-серверном варианте рекомендуется выполнять средствами используемой СУБД. Подробнее см. здесь.

Резервное копирование будет состоять из нескольких шагов:

1. Выполнение резервного копирования собственно базы данных.

2. Выполнение резервного копирования журнала регистрации. Организуется при необходимости иметь возможность просмотра журнала после восстановления резервной копии.

3. Выполнение резервного копирования хранилища двоичных данных. Копирование выполняется с помощью встроенного языка или стандартной функции Управление хранилищем двоичных данных.

Восстановление из резервной копии (в этом случае) выполняется в таком же порядке:

1. Восстановление базы данных из резервной копии.

2. Восстановление журнала регистрации из резервной копии (если журнал резервировался). Восстановление журнала регистрации необходимо выполнять при остановленном кластере серверов.

3. Восстановление хранилища двоичных данных из резервной копии (если выполнялось резервирование хранилища двоичных данных).

Смотри также:

● Хранилище двоичных данных (см. здесь).

На мобильной платформе резервное копирование следует выполнять штатными средствами на ОС iOS и с помощью специализированных программ для ОС Android.

Имеется возможность настроить резервное копирование непосредственно на самом мобильном устройстве. Имеется возможность настроить выполнение резервного копирования в двух вариантах:

1. перед обновлением приложения;

1. автоматическое копирование (перед запуском приложения).

Для настройки резервного копирования следует открыть диалог изменения свойств приложения и нажать кнопку Администрирование. В открывшемся меню следует выбрать пункт Резервное копирование.

В открывшейся форме можно указать следующие настройки резервного копирования:

● В поле Расположение резервных копий (на этом устройстве) указывается путь в локальной файловой системе устройства, где будут создаваться резервные копии. По умолчанию в данное свойство подставляется каталог backup, расположенный в каталоге документов на мобильном устройстве.

● Переключатель Создавать резервную копию при обновлении приложения позволяет включить данную возможность.

● Значение свойства Период автоматического создания резервных копий (дней) позволяет указать, с какой периодичностью будет выполняться создание резервных копий. Если в данном свойстве указано значение 0, то это означает, что автоматическое резервное копирование выполняться не будет. В противном случае резервное копирование будет выполняться перед фактическим запуском приложения в том случае, если от момента создания предыдущей резервной копии прошло больше времени, чем указано в настройке.

● Размер хранимого стека резервных копий задается свойством Количество резервных копий. Значение этого свойства, равное 0, означает, что количество сохраняемых резервных копий не ограничивается системой, а ограничивается только размером свободного пространства на выбранном накопителе. Резервные копии, создаваемые перед обновлением мобильного приложения, также учитываются при вычислении размера стека.

Также на форме присутствуют кнопки для создания резервной копии (Создать резервную копию) и восстановления базы данных из резервной копии (Восстановить…). При попытке восстановления базы данных предлагается выбрать резервную копию, из которой будет восстановлена текущая база. Список получается автоматически по содержимому каталога, указанного в свойстве Расположение резервных копий (на этом устройстве).

В процессе работы системы «1С:Предприятие» могут возникать различные нештатные ситуации ‑ отключение питания компьютера или мобильного устройства, «зависание» операционной системы, сбои оборудования и прочее. Такие ситуации, возникшие в процессе записи изменений в информационную базу системы «1С:Предприятие» (особенно при работе в файловом варианте), могут привести к ее некорректному состоянию. Внешние проявления некорректного состояния информационной базы могут быть различными, вплоть до невозможности запуска.

Процедура Тестирование и исправление информационных баз предназначена для диагностики и устранения ошибочных состояний информационных баз, имеющих различный формат (файловый или клиент-серверный). Данная процедура может применяться как для информационных баз, используемых на персональных компьютерах, так и для информационных баз, используемых на мобильных устройствах.

Для запуска режима используется пункт меню Конфигуратора Администрирование ‑ Тестирование и исправление ИБ. На экран выводится диалог:

Рис. 76. Тестирование и исправление информационной базы

В списке проверок и режимов следует установить требуемые виды выполняемых действий. Виды тестирования можно производить независимо друг от друга. Для обоих вариантов (файловый и клиент-серверный) возможна проверка логической и ссылочной целостности данных, пересчет итогов, реструктуризация и реиндексация базы данных. Для файлового варианта информационной базы дополнительно возможно выполнение сжатия таблиц базы данных. Для клиент-серверного варианта доступен режим проверки целостности хранения двоичных данных (см. здесь).

Проверки логической целостности, ссылочной целостности и целостности хранения двоичных данных могу быть выполнены, каждая, только для указанного списка видов объектов конфигурации. Такое указание может потребоваться, например, для сокращения времени самой проверки или если есть подозрение на проблемы, например, только в регистрах сведений текущей информационной базы. При проверке логической и ссылочной целостности информационной базы следует помнить, что вне зависимости от количества выбранных типов объектов метаданных, определенный набор проверок будет выполнен по всем таблицам всех объектов конфигурации.

Для некоторых распределенных информационных баз, у которых возможно получение данных, содержащих ссылки на объекты, не расположенные в тестируемой информационной базе, снятие флажка Проверка ссылочной целостности информационной базы позволит отключить создание «несуществующих» данных и как следствие не приведет к передаче этих данных в другие узлы распределенной информационной базы.

При выполнении операции тестирования и исправления информационной базы выполняется проверка того, что в основной таблице соответствующего объекта (справочник, план видов характеристик, план видов расчетов, план счетов) существует не более одной записи для каждого предопределенного элемента в каждой области данных. При обнаружении дублей у них снимается признак предопределенности и устанавливается пометка удаления.

Проверка Реструктуризация таблиц расширений конфигурации может быть включена только если одновременно с этим выбрана Проверка логической целостности расширений конфигурации и выбран режим Тестирование и исправление. Если расширения конфигурации входят в состав разделителей (свойство Разделение расширений конфигурации установлено в значение Использовать для одного или нескольких разделителей), то существует возможность указать, в каких областях данных будут выполняться операции с расширениями. Для этого предназначена таблица Разделение данных расширений конфигурации. Каждая строка в этой таблице описывает одну область данных. Параметры области указываются в одной строке, где для каждого разделителя выделяется отдельная колонка.

Режим Реиндексация таблиц информационной базы выполняет реиндексацию всех индексов, которые созданы для конкретной таблицы (включая дополнительные индексы объектов).

Режим Проверка и включение функциональности уровня КОРП предназначена для проверки (режим «только тестирование») или актуализации (режим «тестирование и исправление») состояния информационной базы в зависимости от различных настроек:

● Параметр информационной базы Использовать дополнительные индексы:

● Параметр установлен. Все найденные дополнительные индексы проверяются на соответствие тем, которые указаны в конфигурации. Несоответствующие индексы пересоздаются с нужной структурой, соответствующие остаются без изменений. Создаются дополнительные индексы, которые есть в конфигурации, но отсутствуют в информационной базе. Формируется диагностическое сообщение с перечнем объектов, для которых созданы дополнительные индексы.

● Параметр сброшен. Все найденные дополнительные индексы удаляют из информационной базы. Формируется диагностическое сообщение с перечнем объектов, для которых удалены дополнительные индексы.

Подробнее про дополнительные индексы см. здесь.

Под списком режимов расположены несколько групп настроек:

● В первой группе выбирается, что необходимо выполнить: тестирование или тестирование и исправление. В первом случае программа проведет проверку информационной базы без внесения в нее каких-либо изменений. Во втором случае будут выполнены директивы, указанные во второй группе настроек. Смысл переключателей понятен из их названия.

● Настройки второй группы определяют, что будет делать система при наличии ссылок на несуществующие объекты и при частичной потере данных в существующих объектах.

● Третья группа элементов управления позволяет выполнять длительные процедуры тестирования и исправления в несколько сессий.

Флажок Прервать выполнение проверки через позволяет задать интервал времени, по истечении которого тестирование будет прервано, а параметры тестирования и исправления сохранены до следующей сессии конфигуратора.

Флажок Продолжить прерванное ранее тестирование позволяет продолжить процесс с того места, на котором он был прерван в предыдущей сессии тестирования и исправления.

События тестирования и исправления отображаются в журнале регистрации.

Для запуска тестирования необходимо нажать кнопку Выполнить. Тестирование может быть прервано нажатием комбинации клавиш Ctrl + Break.

Если при настройке операции тестирования и исправления информационной базы выбраны только параметры Проверка логической целостности расширений конфигурации или Реструктуризация расширений конфигурации, то монопольный режим для всей информационной базы не требуется и не устанавливается. В остальных случаях будет сделана попытка установка монопольного режима для выполнения требуемых действий.

В случае обнаружения невозможности установки на экран выводится предупреждение: Не удалось переключить доступ в монопольный режим. Имеются работающие пользователи. Для получения информации о работающих пользователях нужно открыть список активных пользователей (выбрать пункт Администрирование ‑ Активные пользователи, см. здесь).

После установки монопольного режима (если это требуется), запускается процесс выполнения действий, указанных при настройке выполнения операции тестирования и исправления, а в окно сообщений выводится протокол выполнения этой операции.

Если монопольный режим устанавливался перед выполнением операции тестирования и исправления, то он (монопольный режим) будет снят по окончанию этой операции.

При установке режима Сжатие таблиц информационной базы (для файлового варианта информационной базы) будет выполняться дополнительная оптимизация, связанная с размещением всех необходимых данных, необходимых для открытия информационной базы, вначале файла 1Cv8.1CD непрерывным блоком данных. Такая оптимизация ускоряет открытие информационной базы, особенно в случае конфигураций с большим количеством таблиц в информационной базе и находящихся на сетевых ресурсах. После выполнения реструктуризации информационной базы, связанной с изменением структуры таблиц, эффект от сжатия перестает наблюдаться и рекомендуется повторно выполнить сжатие таблиц информационной базы.

Действия, которые выполняются в данном диалоге, можно выполнить с помощью команды /IBCheckAndRepair командной строки пакетного запуска конфигуратора (подробнее см. здесь).

В комплект поставки входит утилита восстановления файлового варианта базы данных (chdbfl). Описание работы с утилитой см. здесь.

Для запуска режима необходимо открыть изменения свойств приложения и нажать кнопку Администрирование. В открывшемся меню следует выбрать пункт Тестирование и исправление.

В открывшейся форме необходимо указать:

● какие виды действий будут выполняться,

● будет выполняться только тестирование или тестирование и исправление (флажок Исправлять автоматически),

● каким будет поведение системы при обнаружении ссылок на несуществующие объекты;

● каким будет поведение системы при обнаружении частичной потере данных объектов информационной базы.

После выполнения всех установок следует нажать кнопку Выполнить (в правом вернем углу формы).

Во время выполнения тестирования и исправления на экране будет присутствовать диалог, отображающий ход процесса, и содержащий кнопку Отмена. Нажатие кнопки приведет к прерыванию операции тестирования и исправления.

В случае необходимости отменить назначение главного узла распределенной информационной базы, можно воспользоваться команда командной строки /ResetMasterNode командной строки пакетного запуска конфигуратора. Эта операция равноценна вызову метода УстановитьГлавныйУзел(Неопределено) объекта ПланыОбменаМенеджер.

Необходимость в таком действии в том случае, например, если возникла необходимость выделить какое-либо из поддеревьев распределенной информационной базы в самостоятельную информационную базу или переподчинить какой-либо из узлов распределенной информационной базы. Более подробную информацию о распределенной информационной базе можно получить в книге.

При необходимости выполнить удаление области данных или всей информационной базы, необходимо воспользоваться командой /EraseData командной строки пакетного запуска конфигуратора. Удаляемая область определяется с помощью параметра /Z командной строки запуска. Более подробно про удаление области можно прочитать в книге.

Для удаления данных необходимо, чтобы пользователь, от лица которого выполняется удаление, обладал правом Администрирование, и имелась возможность получить монопольный доступ к информационной базе.

Для выполнения административных обязанностей часто требуется выяснить, какие события происходили в определенный момент времени или какие действия выполнял тот или иной пользователь.

Для этих целей предназначен журнал регистрации. В этом журнале могут фиксироваться различные события. С его помощью администратор может получить историю работы пользователей с системой.

Журнал регистрации не хранится в базе данных и не сохраняется при операциях загрузки/выгрузки информационной базы.

При работе пользователей система «1С:Предприятие» фиксирует в журнале основные действия, выполняемые пользователем по модификации данных информационной базы, выполнению регламентных операций, подключению и отключению от системы и т. д.

Журнал регистрации работает как в режиме Конфигуратор, так и в режиме 1С:Предприятие. Описание работы с журналом регистрации в режиме 1С:Предприятие описан в справке стандартной функции Журнал регистрации. Описание доступа к стандартным функциям см. здесь.

Журнал регистрации может формироваться в двух форматах:

● Последовательный формат (формат .lgf). Более подробную информацию см. здесь.

● Формат SQLite (формат .lgd). Поддержка данного формата включена версии 8.3.5. Начиная с версии 8.3.22 использование данного формата в новых информационных базах и конвертация в данный формат не поддерживаются. Поддержка данного формата будет прекращена в следующих версиях. Описание работы с форматом SQLite можно получить в предыдущих версиях документации.

В зависимости от версии системы «1С:Предприятия», по умолчанию используются различные форматы журналов:

● В «1С:Предприятии» версии 8.3.4 и предшествующих версиях может быть использован только последовательный формат журнала регистрации.

● В «1С:Предприятии» версий 8.3.5 ‑ 8.3.11 по умолчанию используется формат SQLite. Не поддерживается смена формата журнала регистрации.

● В «1С:Предприятии» версии 8.3.12 и последующих версиях по умолчанию используется последовательный формат. Поддерживается возможность смены формата используемого журнала регистрации.

● В «1С:Предприятии» версии 8.3.22 и последующих версиях для новых информационных баз используется последовательный формат. Смена формата журнала регистрации отключена. Существует возможность просмотра журнала регистрации в формате SQLite.

При смене формата журнала регистрации во время работы системы, выбранный формат журнала регистрации сохраняется в информационной базе. В результате при восстановлении информационной базы из резервной копии или файла выгрузки (.dt) формат журнала регистрации также будет восстановлен. Это следует иметь ввиду, когда в версии 8.3.22 (и последующих версиях) восстанавливается информационная база, в которой установлен формат SQLite и которая была выгружена в dt-файл в предыдущих версиях.

События в журнале регистрации идентифицируются строкой. При этом для системных событий используются комбинации символов _$ и $_ (например, _$InfoBase$_.MasterNodeUpdate или _$PerformError$_). _$InfoBase$_.MasterNodeUpdate отобразится в виде строки Информационная база. Изменение главного узла. Использование этих комбинаций в именах событий, записываемых из встроенного языка, с помощью метода ЗаписьЖурналаРегистрации() запрещено. Созданные при помощи этого метода события отображаются как есть.

Журнал регистрации формата .lgf хранится в текстовых файлах со следующими расширениями:

● 1Cv8.lgf ‑ общая информация журнала регистрации.

● *.lgp ‑ фрагмент журнала регистрации.

● *.lgx ‑ индексный файл одноименного фрагмента журнала регистрации. Размер индексного файла составляет примерно 10% от «своего» файла журнала регистрации.

Формирование индексного файла журнала регистрации зависит от используемого варианта работы:

● Файловый вариант ‑ индексирование журнала регистрации не выполняется. Индексный файл не создается и не используется.

● Клиент-серверный вариант ‑ индексирование журнала регистрации выполняется. Индексные файлы создаются и используются. Количество потоков индексирования равно половине от количества рабочих ядер компьютера менеджера кластера серверов, но не может быть больше 8 и меньше 1 потока.

Журнал располагается:

● Для файлового варианта информационной базы ‑ в подкаталоге 1Cv8Log каталога информационной базы.

● Для клиент-серверного варианта информационной базы ‑ в подкаталоге 1Cv8Log каталога информационной базы в каталоге служебных файлов кластера. Имя каталога можно определить по файлу реестра данных кластера.

Для сохранения журнала регистрации нужно открыть его и выбрать пункт Файл ‑ Сохранить копию. На экран выводится диалог выбора каталога и файла, в который будет произведена выгрузка, а также тип файла (по умолчанию указывается тип журнала регистрации *.lgf). Выгрузка также возможна в формате XML (описание формата см. здесь).

Пример выгрузки журнала регистрации:

<v8e:EventLog
   xmlns:v8e = "http://v8.1c.ru/eventLog"
   xmlns:xsd = "http://www.w3.org/2001/XMLSchema"
   xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance">
    <v8e:Event>
   <v8e:Level>Warning</v8e:Level>
   <v8e:Date>Дата события</v8e:Date>
   <v8e:Application>Enterprise</v8e:Application>
   <v8e:ApplicationPresentation>
     1С:Предприятие</v8e:ApplicationPresentation>
   <v8e:EventName>имя события</v8e:EventName>
   <v8e:EventPresentation>
     презентация события</v8e:EventPresentation>
   <v8e:UserID>00000000-0000-0000-0000-000000000001</v8e:UserID>
   <v8e:UserName>Иванов</v8e:UserName>
   <v8e:Computer>Ivanov</v8e:Computer>
   <v8e:MetadataName>Справочники.Номенклатура</v8e:MetadataName>
   <v8e:MetadataPresentation>
     Справочники Номенклатура</v8e:MetadataPresentation>
   <v8e:Comment>Комментарий</v8e:Comment>
   <v8e:Data xsi:type="xsd:string">Какие-то данные</v8e:Data>
   <v8e:DataPresentation>Описание данных</v8e:DataPresentation>
    </v8e:Event>
</v8e:EventLog>

Для просмотра архива записей журнала регистрации необходимо:

● В Конфигураторе: нужно выбрать пункт Главное меню ‑ Файл ‑ Открыть и в стандартном диалоге выбора файла указать тип файла Журнал регистрации (*.lgd, *.lgf). Выбрать нужный файл архива и нажать кнопку Открыть. Индексация открываемого файла будет выполняться в фоновом режиме. Индексные файлы будут создаваться в каталоге временных файлов Конфигуратора и будут удалены после окончания работы с журналом.

● В стандартной функции просмотра журнала регистрации: нужно выбрать пункт Еще ‑ Просмотреть из файла, затем в стандартном диалоге выбора файла выбрать нужный файл архива и нажать кнопку Открыть.

Настройка автоматического обновления и интервала обновления производится стандартным для табличного поля механизмом настройки списка.

Не поддерживается возможность просмотра архива журнала регистрации, созданного в системе «1С:Предприятие» версий 8.0 и 8.1.

С помощью пункта меню Администрирование ‑ Настройка журнала регистрации можно настроить подробность регистрации событий в журнале регистрации. В случае сетевой работы выбранную установку можно сохранить только тогда, когда с конфигурацией кроме администратора никто не работает.

Рис. 77. Настройка журнала регистрации

При создании новой информационной базы для журнала устанавливается режим регистрации событий всех уровней важности и периодичность разделения на файлы ‑ неделя.

Для журнала регистрации доступна настройка разделения журнала по периодам. Это связано с тем, что записи журнала регистрации хранятся в файлах. Каждый файл содержит записи определенного периода. Размер периода задается в поле Разделять хранение журнала регистрации по периодам. Новый файл открывается при наступлении (указывается в значении настройки) каждого нового:

● часа,

● дня,

● недели,

● месяца,

● года.

В процессе эксплуатации системы в журнале регистрации может накопиться значительное число записей. Для сокращения числа записей следует открыть окно настройки журнала и нажать кнопку Сократить. На экран выводится окно:

Рис. 78. Сокращение журнала регистрации

Сокращение записей производится до даты, которая задана в поле Удалить события до. При сокращении будут удалены все записи журнала регистрации, дата которых строго меньше указанной даты. В результате сокращения, в журнале регистрации останутся все записи за пограничный день (т. е. начиная с времени 00:00 пограничной даты) и все последующие данные. При сокращении журнала регистрации система принимает во внимание фактический режим разделения журнала (как во все прошлые периоды, так и в текущий момент времени).

Если требуется сохранить удаляемые записи, то нужно установить флажок Записать удаляемые записи в файл и указать имя файла-архива.

Для журнала регистрации имеется возможность периодически сокращать журнал и при этом иметь возможность просматривать уже удаленные события журнала. Для этого при сокращении журнала с записью удаляемых записей в файл следует установить флажок Сохранять разделение хранения журнала по периодам и объединять с сохраненным ранее журналом.

Если в текущей информационной базе журнал регистрации находится в формате SQLite, то имеется возможность конвертировать его в последовательный формат. Обратная конвертация не поддерживается.

В зависимости от варианта информационной базы, для выполнения операции изменения формата журнала регистрации требуется разный доступ к файлу информационной базы:

● Файловый вариант ‑ для изменения формата требуется монопольный доступ к файлу информационной базы.

● Клиент-серверный вариант ‑ изменение формата может выполняться одновременно с работой пользователей. При этом:

● При изменении формата журнала регистрации исключена возможность потери некоторых событий журнала регистрации, которые были записаны в процессе изменения формата и после него.

● Если при конвертации журнала из формата SQLite в последовательный произошла ошибка, то продолжает использоваться формат SQLite, если ошибка возникла при записи в последовательный формат, и начинает использоваться последовательный формат, если ошибка связана с чтением из формата SQLite.

Изменение формата сопровождается записью в журнал регистрации события Информационная база. Изменение параметров журнала регистрации (_$InfoBase$_.EventLogSettingsUpdate). В комментарии будет указано, в какой формат были преобразованы данные журнала регистрации.

Если текущий журнал регистрации находится в формате SQLite, то при открытии формы настройки журнала регистрации открывается диалог следующего вида.

Рис. 79. Информация об устаревании формат SQLite

Нажатие гиперссылки Перейти на последовательный формат (рекомендуется) откроет диалог настройки конвертации журнала регистрации. Этот диалог выглядит следующим образом:

Рис. 80. Преобразование в последовательный формат

Одновременно с преобразованием предоставляется возможность задать разделение журнала регистрации по периодам.

После того, как формат журнала регистрации успешно изменен на последовательный, файл журнала регистрации в формате SQLite удаляется.

Система «1С:Предприятие» обеспечивает возможность ведения технологического журнала, в который помещается информация от всех приложений, относящихся к системе «1С:Предприятие».

Технологический журнал предназначен для выявления ошибок, возникающих при эксплуатации системы, и диагностики работы системы службой технической поддержки фирмы «1С», а также для анализа технологических характеристик работы системы.

Состав и свойства событий технологического журнала могут меняться при выпуске обновлений платформы.

Поскольку технологический журнал представляет собой набор текстовых файлов, хранящихся в различных каталогах, он может быть использован разработчиками прикладных решений для анализа различных режимов работы системы «1С:Предприятие» и прикладных решений.

Технологический журнал может вестись на любом компьютере, на котором установлена система «1С:Предприятие». За ведение технологического журнала отвечает конфигурационный файл, в котором описываются:

● каталог, в котором будут располагаться файлы технологического журнала;

● состав информации, которая будет помещаться в технологический журнал;

● время, в течение которого хранятся файлы технологического журнала;

● структуру хранения файлов технологического журнала, правила ротации, формат и необходимость архивации файлов;

● параметры дампа, создаваемого при аварийном завершении приложения.

По умолчанию конфигурационный файл отсутствует. Это означает, что технологический журнал включен и настроен на сохранение минимальных дампов при аварийном завершении приложения в каталог (для ОС Windows):

%LOCALAPPDATA%\1C\1cv8\dumps

При необходимости может быть выполнена произвольная настройка журнала регистрации с помощью отдельного конфигурационного файла. Этот файл должен иметь имя logcfg.xml и располагаться в каталоге конфигурационных файлов системы «1С:Предприятие». Подробнее о структуре и возможностях конфигурационного файла см. здесь.

Система «1С:Предприятие» автоматически, с периодичностью 60 секунд, опрашивает каталоги конфигурационных файлов на предмет наличия файла logcfg.xml и анализирует его состав. Таким образом, изменение параметров технологического журнала может быть выполнено на ходу, без перезапуска работающих приложений системы «1С:Предприятие».

Конфигурационный файл позволяет указать различные настройки, которые помогут структурировать технологический журнал, выбрать его формат и настроить время жизни файлов журнала.

Настройку формирования дампов аварийного завершения с помощью конфигурационного файла технологического журнала можно выполнять только в том случае, если система работает под управлением ОС Windows. При работе под управлением ОС Linux или macOS, настройка формирования дампов выполняется с помощью инструментов этих операционных систем.

В простейшем виде конфигурационный файл может иметь, например, следующее содержимое:

<config xmlns="http://v8.1c.ru/v8/tech-log">
    <log location="c:\1c\logs" history="1">
   <event>
    <eq property="name" value="conn"/>
   </event>
    </log>
    <dump location="c:\1c\dumps" create="1" type="2"/>
</config>

Данный конфигурационный файл указывает на следующее:

● в технологическом журнале регистрируются все события установки и разрыва клиентского соединения с сервером;

● файлы технологического журнала располагаются в каталоге C:\1c\logs;

● файлы технологического журнала хранятся в течение одного часа;

● файлы дампа помещаются в каталог C:\1c\dumps;

● файлы дампа содержат всю доступную информацию (содержимое всей памяти процесса).

При отсутствии конфигурационного файла используются следующие параметры:

● Технологический журнал ‑ выключен.

● Технологический журнал по умолчанию ‑ включен (см. здесь).

● Дампы минимального размера.

● Дампы сохраняются в каталог %LOCALAPPDATA%\1C\1cv8\dumps профиля текущего пользователя.

Подробнее о структуре и возможностях конфигурационного файла см. здесь.

Работа с конфигурационным файлом в ОС Linux и macOS практически не отличается от таковой в ОС Windows, за исключением следующих особенностей:

● Файл должен располагаться в каталоге конфигурационных файлов системы «1С:Предприятие».

● Каталог, в котором будет формироваться технологический журнал, должен быть доступен по записи для пользователя, от имени которого работает приложение (сервер, клиентские приложения, расширения веб-сервера и т. д.), которое записывает данные в технологический журнал.

Для записи событий, возникающих в критических ситуациях (с точки зрения системы «1С:Предприятие») предназначен технологический журнал по умолчанию. Для этого журнала создается фиксированный фильтр событий, который формирует платформа и который невозможно изменить.

Технологический журнал по умолчанию имеет следующие настройки:

● Каталог файлов технологического журнала по умолчанию:

● ОС Windows: %LOCALAPPDATA%\1C\1cv8\logs.

● ОС Linux: ~/.1cv8/1C/1cv8/logs.

● ОС macOS: ~/.1cv8/1C/1cv8/logs.

● Информация удаляется из технологического журнала по умолчанию через 24 часа.

● В технологический журнал по умолчанию попадают события SYSTEM с уровнем ERROR.

Указанные настройки можно изменить с помощью элемента <defaultlog> (см. здесь). Настройка правил формирования событий, которые регистрируются в технологическом журнале по умолчанию выполняется с помощью элемента <system> (см. здесь).

Технологический журнал представляет собой каталог, в подкаталогах которого располагаются файлы с собранными технологическими данными. Описание файлов технологического журнала см. здесь. Описание файла конфигурации технологического журнала см. здесь.

Описание настройки формирования дампов аварийного завершения работы компонентов системы «1С:Предприятие» см. здесь.

В приведенных ниже примерах предполагается, что «1С:Предприятие» установлено стандартным способом в каталог C:\Program Files\1cv8.

Важно иметь в виду, что в каталог технологического журнала при некоторых его настройках могут выводиться данные очень большого объема. Поэтому на диске, где планируется размещение файлов технологического журнала, должно быть достаточно свободного места.

Далее приведено несколько примеров файлов logcfg.xml, содержащих наиболее часто используемые конфигурации технологического журнала.

Если файл logcfg.xml отсутствует в каталоге конфигурационных файлов (см. здесь) «1С:Предприятия», то технологический журнал не создается. Если файл logcfg.xml необходим для правильной настойки дампов, то он не должен содержать ни одного элемента log. Следующий пример определяет необходимость построения полного дампа приложения при его аварийном завершении. Дампы помещаются в каталог C:\v8\dumps.

<config xmlns="http://v8.1c.ru/v8/tech-log">
    <dump location="C:\v8\dumps" create="1" type="3"/>
</config>

Приведенный ниже конфигурационный файл определяет вывод в технологический журнал всех событий вместе со всеми свойствами. Журнал будет сохраняться в течение недели (168 часов). Объем выводимой информации при этом будет очень большим, однако она может быть полезна при анализе сложных нештатных ситуаций. Данную конфигурацию рекомендуется использовать на этапе тестирования и при расследовании ошибок.

<config xmlns="http://v8.1c.ru/v8/tech-log">
    <log location="C:\v8\logs" history="168">
   <event>
    <ne property="name" value=""/>
   </event>
   <property name="all">
   </property>
    </log>
</config>

Следующий конфигурационный файл определяет, что технологический журнал будет содержать только обращения «1С:Предприятия» СУБД, а также информацию об ошибочных ситуациях. Объем выводимой информации меньше, чем при полном технологическом журнале, но тоже может быть очень большим.

<config xmlns="http://v8.1c.ru/v8/tech-log">
    <log location="C:\v8\logs" history="168">
   <event>
    <eq property="name" value="dbmssql"/>
   </event>
   <event>
    <eq property="name" value="dbpostgrs"/>
   </event>
   <event>
    <eq property="name" value="db2"/>
   </event>
   <event>
    <eq property="name" value="dboracle"/>
   </event>
   <event>
    <eq property="name" value="excp"/>
   </event>
   <property name="all">
   </property>
    </log>
</config>

Этот конфигурационный файл создает технологический журнал небольшого объема, в котором содержится информация о запуске и завершении приложений, установке и разрыве соединений с кластером серверов «1С:Предприятия», действиях администратора кластера и об ошибочных ситуациях в работе «1С:Предприятия». Такой журнал в большинстве случаев достаточен для расследования ошибочных ситуаций как в конфигурации, так и в технологической платформе «1С:Предприятие».

<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="C:\v8\logs" history="168">
    <event>
   <eq property="name" value="admin"/>
    </event>
    <event>
   <eq property="name" value="conn"/>
    </event>
    <event>
   <eq property="name" value="excp"/>
    </event>
    <event>
   <eq property="name" value="proc"/>
    </event>
    <event>
   <eq property="name" value="qerr"/>
    </event>
    <event>
   <eq property="name" value="scom"/>
    </event>
    <property name="all"/>
 </log>
</config>

По сравнению с предыдущим, данный конфигурационный файл добавляет все операции, длительность которых превышает 10 секунд. Это может оказаться полезным для обнаружения действий пользователей, которые выполнялись длительное время, с целью, например, их последующей оптимизации. Длительность событий выражается в сотнях микросекунд.

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
 <dump create="false"/>
 <log location="C:\v8\logs" history="168">
    <event>
   <eq property="name" value="admin"/>
   <gt property="duration" value="100000"/>
    </event>
    <event>
   <eq property="name" value="conn"/>
   <gt property="duration" value="100000"/>
    </event>
    <event>
   <eq property="name" value="excp"/>
   <gt property="duration" value="100000"/>
    </event>
    <event>
   <eq property="name" value="proc"/>
   <gt property="duration" value="100000"/>
    </event>
    <event>
   <eq property="name" value="qerr"/>
   <gt property="duration" value="100000"/>
    </event>
    <event>
   <eq property="name" value="scom"/>
   <gt property="duration" value="100000"/>
    </event>
    <property name="all"/>
 </log>
</config>

В системе «1С:Предприятие» значительная часть данных хранится в виде ссылок. Например, при вводе документов многие реквизиты документа могут заполняться путем выбора значения из списка или документа из списка документов. Такие реквизиты являются ссылками на элементы соответствующих списков.

Использование ссылок позволяет избежать многократного исправления одной и той же информации в разных местах. Например, после ввода и распечатки ряда документов выяснилось, что наименование организации-контрагента, на которую были выписаны эти документы, указано неправильно. Так как наименование контрагента вводилось в документы путем выбора из списка контрагентов, достаточно отредактировать наименование контрагента только в списке ‑ измененное наименование будет отражено в документах автоматически, и достаточно будет только заново построить печатные формы.

Однако если удалить организацию-контрагента из списка, то во всех документах, в которых она использовалась, останутся так называемые «неразрешенные ссылки» ‑ ссылки на несуществующий объект.

Для исключения таких ситуаций в системе «1С:Предприятие» существует механизм контроля ссылочной целостности, о котором пойдет речь в этом разделе.

Механизм контроля ссылочной целостности разделяет процесс удаления объектов данных, на которые могут существовать ссылки (списки и документы), на два этапа.

На первом этапе пользователи выполняют пометку объектов на удаление. При этом помеченный на удаление объект практически ничем не отличается в использовании от обычного объекта.

На втором этапе администратор системы или иное лицо, для которого определены соответствующие права (установлено право ИнтерактивноеУдалениеПомеченных для соответствующих видов списков и документов), выполняет специальную процедуру ‑ удаление помеченных объектов, которая реализована в виде стандартной функции Удаление помеченных объектов (см. здесь). В ходе выполнения этой процедуры происходит полный анализ всех ссылок на помеченные объекты, и могут быть удалены только те объекты, на которые ссылки либо отсутствуют, либо располагаются в объектах, которые также помечены для удаления.

Фактически процедура удаления помеченных объектов является регламентной. Ее рекомендуется выполнять периодически по мере накопления помеченных объектов.

Система «1С:Предприятие» позволяет удалять лишнюю или устаревшую информацию в двух режимах:

● Непосредственное удаление объектов ‑ не производится анализ использования удаляемого объекта в других объектах базы данных.

● Использование контроля ссылочной целостности ‑ объекты сначала помечаются на удаление, а затем производится контроль наличия ссылок на эти объекты в других объектах.

Если пользователь работает в режиме непосредственного удаления, то дополнительная ответственность ложится и на пользователя, выполняющего удаление объектов, и на администратора системы, определяющего права пользователей и действия системы при неразрешенных ссылках. Работа системы без контроля ссылочной целостности может быть, например, использована специалистами в процессе отладки прикладного решения. Если контроль ссылочной целостности не используется, то удаление объектов происходит непосредственно (без пометки на удаление), и появляется возможность образования неразрешенных ссылок.

Самым радикальным способом установки режима контроля ссылочной целостности является отключение в конфигурации в целом прав непосредственного удаления объектов. Таким способом полностью исключается возможность в пределах данного прикладного решения непосредственно удалять объекты. Пользователи будут иметь возможность только помечать объекты на удаление.

Предоставление прав на непосредственное удаление, а также установку и снятие пометки удаления объектов производится для каждого вида объектов конфигурации. Если по данному виду для выбранного набора прав (роли) установлено право ИнтерактивноеУдаление, то пользователи, для которых определена эта роль, имеют возможность непосредственного удаления объектов данного вида. Установка прав производится при разработке прикладного решения.

Аналогично предоставляется право установки и снятия пометки удаления объектов, а также удаления помеченных объектов.

Разумеется, только отключение в конфигурации права ИнтерактивноеУдаление обеспечивает согласованное использование механизма ссылочной целостности всеми пользователями.

Если режим контроля ссылочной целостности не используется (в конфигурации установлено право ИнтерактивноеУдаление у конкретного пользователя для конкретного вида объекта конфигурации), в списках списков и в журналах документов пользователь имеет возможность использовать пункт меню Удалить непосредственно (клавишу Shift + Del или соответствующую кнопку панели инструментов) для удаления данного вида объектов. При этом данный объект будет удален без проверки ссылок на него в других объектах.

При использовании механизма контроля ссылочной целостности в списках списков и журналах документов в меню Еще (Все действия) присутствует пункт Пометить на удаление/Снять пометку. При выборе данного пункта меню выполняется пометка объекта на удаление. Помеченный на удаление объект отмечается в левой колонке списка значком, изображающим перечеркнутый образ объекта.

Выбор пункта меню Еще ‑ Пометить на удаление/Снять пометку удаления (Все действия ‑ Пометить на удаление/Снять пометку удаления) помечает объект на удаление, а для помеченного на удаление объекта снимает у него пометку удаления.

Возможность установки и снятия пометки удаления конкретным пользователем также регламентируется правами доступа (отдельно пометка и снятие пометки).

В основном помеченные на удаление объекты используются так же, как и обычные. Они также показываются в списках, по ним может выполняться поиск и т. д. Помеченные на удаление объекты могут быть открыты и изменены.

Помеченный на удаление документ не может быть проведен. При попытке выполнить проведение помеченного на удаление документа выдается соответствующее сообщение, и проведение документа не выполняется.

Стандартные функции ‑ это набор инструментов системы, предназначенный для выполнения различных сервисных операций, которые могут потребоваться при администрировании информационной базы.

Доступ к стандартным функциям возможен только в режиме 1С:Предприятие. Для получения доступа к стандартным функциям необходимо включить соответствующий параметр в окне настроек (Сервис ‑ Параметры ‑ Режим технического специалиста).

Ниже приведен полный список стандартных функций с кратким описанием.

Для вызова необходимой стандартной функции следует открыть окно Функции для технического специалиста, выбрать ветвь Стандартные функции и в открывшемся списке выбрать нужную стандартную функцию (если она доступна).

Описание стандартных функций приводится в справке.